One of Internet Explorer’s (IE) most commonly encountered bug is when using z-index. I experienced this recently when using the DDSlider plugin for WordPress along with a drop down navigation.
Whilst doing some browser testing I noticed that the drop down menu hides behind the DDSlider. I tried to fix this using z-index. I applied positions and z-index to the offending elements but they still did not behave properly.
After Googling the issue I came across this post which explains the problem perfectly. I needed to apply z-indexes to higher level elements that sit side by side in the DOM. In my example I applied a position:relative; z-index:2 to the #header div and a position:relative; z-index:1 to the #main div. Seems to have done the trick perfectly!
Spinning Progress Wheel
One of my clients recently informed me that a site that I had built had a problem; when some pages were published or updated, the progress wheel would spin until the browser eventually timed out.
It had been a month or so since I had finished the site development and there had been lots of new content and plugins added. I turned on the WordPress debugging and got to work.
Finding the problem
There were a lot of errors being generated, mostly from plugins but also from WP itself. I also noticed a few memory limit issues which I fixed using the .htaccess file.
I got to work isolating the various components. All plugins, themes and content were tested to no avail. Next up I installed the site on different servers. I looked at the database for anomalies, contacted the hosting provider, nothing.
Lying in bed last night I couldn’t sleep, I had to give it another go. I did some more tests on what I thought was the offending plugin and associated database table. Still no joy. In one last ditch attempt I did various Google searches of the symptoms. I jumped from forum to forum and followed links all over the place.
Then I found it. The custom permalink structure of “/%category%/%postname%/” that I have used on nearly every site was the culprit. Now, someone please correct me if I’m wrong, but I’m sure the WordPress codex used to give that exact structure as an example of how to implement “Pretty Permalinks”. Not any longer. Apparently that structure causes performance issues on sites with lots of pages. For every page a whole new set of rewrite rules are created until the system just can’t process it any more.
The solution is to use a non-verbose entry at the start. For example %year% or %month% or both are ideal but %category%, %postname%, %tag% and %author% should be avoided.
Fortunately, the codex has been updated to advise against this practice and the new example “pretty permalink” is /%year%/%postname%/.
For most site you can probably get away with the offending structure. In fact many SEO and WordPress ‘gurus’ recommend it. Just be warned that if your site grows in terms of pages then you may encounter this problem in the future.
Some of the lessons that I’ll take with me:
- Keep up to date with changes to WordPress documentation and best practices.
- Clearly define who takes responsibility for WordPress faults in your project contract.
- Never give up!