tips

It’s dangerous to make assumptions about how users are interacting with and viewing your website. For instance, desktop users who zoom in on websites will wind up activating the mobile view. And some mobile users navigate with a keyboard.
Rather than “Read More” links, be specific: “Read more about ---.” This is important for users with screen readers who are unable to see the association between the “read more” link and the content it references. You can visually hide “---” so that only screen readers will detect it.

That big blue field is a whole bunch of cachegrind.out files in /private/var/tmp. Turns out these files are generated when you have Xdebug enabled, which I do because it's useful to debug PHP as a developer. So, first thing I try to do is delete all these useless files.

I changed where Xdebug saves it's cache files to /tmp in my php.ini file. In my case with MacPorts it's at /opt/local/etc/php54/php.ini.

That big blue field is a whole bunch of cachegrind.out files in /private/var/tmp. Turns out these files are generated when you have Xdebug enabled, which I do because it's useful to debug PHP as a developer. So, first thing I try to do is delete all these useless files.

I changed where Xdebug saves it's cache files to /tmp in my php.ini file. In my case with MacPorts it's at /opt/local/etc/php54/php.ini.

A quick and easy solution to this problem is to have your JS import the breakpoints directly from the CSS values in the DOM. This solution brings the current breakpoint variable into your JS in a way that's Simple & Lightweight DRY Compatible with all browsers that support media queries (IE9+)

Really useful when trying to create a log from unicode data. Try to encode your unicode string as ascii first: unicodeData.encode('ascii', 'ignore') the 'ignore' part will tell it to just skip those characters

Is error reporting on and display errors on in development and off in production? Do not suppress errors in your code. Implement a logging framework. Use a caching strategy. Keep in mind and use programming design patterns and best practices. Use tests in your code and try to automate running these tests every time a change occurs in the code base. Review or at least audit team members’ code. Practice defensive programming. Learn and use OOP principles correctly. Have a solid workflow and processes for developing and deploying code. Differentiate between read / write database queries.

Screw up. Many, many times. Keep screwing up.

In all the testing I have done, home page carousels are completely ineffective.For one, anything beyond the initial view has a huge decrease in visitor interaction. And two, the chances that the information being displayed in the carousel matches what the visitor is looking for is slim. So in that case the carousel becomes a very large banner that gets ignored. In test after test the first thing the visitor does when coming to a page with a large carousel is scroll right past it and start looking for triggers that will move them forward with their task.

A collection of code snippets and pro tips on Drupal

A collection of code snippets and pro tips on Drupal