Ah…the feeling of fixing bugs. It’s very satisfying, but not as satisfying as releasing those fixes to the world. Now is one of those wonderful times for Pizazz.
The first thing I wanted to deal with is that the thumbnail-size property stopped working. Previously, I had used PHP’s str_replace function to change “_125.jpg” to “_theCustomThumbnailSize.jpg”. As it turns out, Zazzle automatically generates the images based on the last number in the filename, hence I was able to implement this nice little feature. However, for some incomprehensible reason Zazzle changed the default number to 152. I’m pretty sure that’s a typo, because the five and two have been switched and that’s it. Generally this would be dangerous for everybody who relies on this default size to use the feed in any of their products.
The fix for this is pretty simple, but I had to fix something else, first. I installed Pizazz on my fresh, new test server and it didn’t work. At all, or at least at all by default. If you chose the lucky tags then it would work perfectly. After awhile I figured out what was wrong: the RSS feed was broken (or, better put, malformed). The titles of the products in some areas contained ampersands (“&”). Normally this is fine, except that they were just ampersands. Under XML (from which RSS derives), the ampersand has a special meaning. It is used to identify special characters; for instance, “>” indicates the greater-than sign (“>”). So, an ampersand on its own is erroneous, and should actually be “&”. Sadly, the XML parser I was using — SimpleXML — isn’t forgiving, and would abort on such lines. Most XML parsers break on these types of things, even Internet Explorer failed to read these feeds (though that browser fails on a lot of things). However, since Pizazz was made for Zazzle, and Zazzle always does things like this, SimpleXML had to go.
I rewrote the parser to use PCRE — Perl-Compatible Regular Expressions — to extract data from the text file without parsing it as true XML. So instead of running the XML parser and pulling out the data from a specialized PHP data structure, I just asked PHP to give me the text in between each “<item>” and “</item>”, then from there pull out the title from “<title><![CDATA[” and “]]></title>”, etc. This also removed the need for a number of verifiers that I wrote in to handle when Zazzle only produces bad RSS every-other request (that happens sometimes). In combination, this results in faster feed-caching and much more forgiving RSS parsing. The number of times that Pizazz abruptly fails due to XML parsing errors has been greatly reduced if not eliminated. Even when Zazzle returns its home page surrounding the RSS data the proper fields can still be extracted!
Great, now I could get back to the bug that I initially wanted to fix: the thumbnail sizer. Well, I could have just changed the parameter for str_replace from 125 to 152, but I’m absolutely sure that Zazzle will change this number again and I’ll have to change that again. So, instead, I just got PCRE to replace “_anyNumberAtAll.jpg” with what I want. That fixed it for now, and should prevent anything like this from happening again.
Then I got a bug report from one of my clients using multisite. Specifically, Pizazz didn’t work on multisite (well, it sort of did). Before, she activated Pizazz on each sub-blog individually, which circumvented the problem where “Network Activate” would crash WordPress’s network dashboard with a E500 Internal Server Error. I was going to fix Network Activate but, considering that there was a way around it and I had other stuff on my mind, I deprioratized it and ended up forgetting about it. Well, she got around to enabling it on the main site, and ended up breaking the network dashboard again. There was no way around this one, so I had to go working on it.
During the first day I successfully fixed the undefined-function error PHP was spewing out by moving Pizazz’s initialization code into a WordPress init-hook, as I technically should have from the beginning. This resulted in a different error: “function get_current_screen is not defined in /…/wp-admin/network/settings.php.”
This one took me 36-hours to debug. I painstakingly scoured the blogs, the WordPress codex, the forums, anywhere Google would take me and never found anything that would solve my problem. Worse off, PHP doesn’t give tracebacks unless you install a debugging plugin, which wasn’t a viable option. I kept on trying new things, including rewriting the settings page entirely. Albeit, the rewrite resulted in a cleaner script and moved the settings into their own page, which was nice, but it was (is) still frustrating.
I ended going onto my client’s server and just putting in a bunch of die calls throughout the source code, trying to pinpoint where everything went wrong. I knew it was in settings.php, and the die calls didn’t help any further. That error kept cropping up in the network dashboard, and I couldn’t figure it out!
Finally, I commented out the code that loaded settings.php because I just wanted to remember what the network dashboard looked like. Then, carelessly, I hovered over and past the Network Settings tab. I froze, then moved my mouse back. I noticed that the Network Settings didn’t have any plugin fields listed. I looked back at the main site dashboard and hovered over the settings there and saw the plugins again. I un-commented the lines that loaded settings.php and looked back. The network dashboard stopped working, but the settings field worked perfectly in the main site dashboard. I wanted to scream.
You can’t register options pages in the network dashboard! As opposed to WordPress raising an error when this was attempted, it prevented the function from being created in the assumption that plugin developers would know what the “undefined function” error meant. They don’t say that you can’t define option tables ANYWHERE in the documentation! I checked, it isn’t there. No wonder so many plugins don’t work in multisite, they don’t document these incompatibilities! All I had to do was change ( is_admin() ) to ( is_admin() and ( ! is_network_admin() ) ) and it worked again. Who the hell manages the codex!
There was much internal screeching, pacing and (for some unhealthy reason) eating that came afterwards. This has to be one of the most frustrating things I have ever had to deal with. One line, one problem that I wouldn’t have had if they had just documented it!
Eh…anyway, here’s the new plugin. All these bugs have been fixed and there are some minor code clean-ups. I don’t remember at which point it was but I rewrote the cache manager to use opendir instead of glob when iterating through the files, because for some reason glob doesn’t always work when opendir does, so that should help any users who had or would of had a problem with this.
Now, I’m going to play with writing a little TinyBASIC compiler to cool off, and when I’m back to Pizazz I’ll implement shortcodes to embed Pizazz product inventories into your posts and pages. Keep tuning in!
Pizazz is available here.