RSS irritations in WordPress
I’m currently working on adding comic thumbnails to the RSS output of our comic site http://www.onezumi.com, but have discovered a very irritating fact: WordPress does not allow img tags in the description field in the RSS XML. As a result most feed readers will not see the images and won’t display them. (the default Firefox feed viewer being one of them). The img tag does get added to the content encoded element, but that’s less supported right now. So my normal technique is to write up a quick plugin to correct this….but apparently that’s not possible. All of the hooks and actions out there do not allow for this be accomplished. So it comes down to the old fashioned “hack the core file” thing to get this fixed. I hate doing that, but in this case there’s no other way to do it. The actual file to hack (for RSS2 feeds) is located in your wp-includes folder and is called feed-rss2.php. There are two lines in there that have the description element, one for if you are using only an excerpt, and the other if you are doing full text feed. Basically you hack the line to put in whatever you want right after the [CDATA[ part, or right before the final ]] of the line.
Of course you will now always need to remember to either add this back in after upgrading versions of WordPress, or keep a copy of this file and just merge it into things afterward (and make sure any updates didn’t affect this file).
The one thing that is unfortunate is I was hoping to be able to add some stuff to my plugins for this for anyone to benefit, but can’t. Oh well.
Design Dilemmas: CSS versus Tables
Sometimes CSS issues aren’t worth fixing. Over at our webcomic site Onezumi.com we had a new requirement that had us displaying 2 different comics on the index page at once. We also wanted to have the news posts associated with each comic also appear on the index (each comic has it’s own category), but side by side, not in a single loop.
The actual code to get separate loops working is a bit tricky, but not too hard once you understand the process. The major issue arose in getting both posts to appear and not overlap or conflict when appearing side by side.
The typical way to do this in a theme is to make both loops into separate HTML div’s, then do a float on them to get them to appear next to each other. The problem comes in when you need to retrofit this into a theme and CSS setup that wasn’t initially set up with this expectation.
The cascading nature of CSS is normally a good thing–the evil comes in due to different web browser compatibility levels, as well as weird “by design” issues with CSS itself. One of the most frustrating things with CSS is that due to the cascade, you may not actually easily know why something isn’t appearing correctly. While the element level can clearly have a specific CSS entry that tells it to do something, there are times when an overarching CSS entry (like a div level img setting behavior) can override your local entry. It involves which CSS entry the browser decides to do first, then second. You would assume that the local entry would trump the div level one, but that’s not always the case.
Anyway, back to my specific problem: The floats for the 2 news entries weren’t working properly. The CSS caused elements from both div’s to overlap, or get pushed under the other div. Or the background wasn’t being extended correctly behind both divs. It was turning into a mess.
Then the answer hit me: screw CSS for placement. While I’m sure many people will choke on this statement: Tables almost always work properly for placement, so use them sometimes where appropriate. In my case all I needed to do was make a simply 2 row table and place each loop inside each td.
Boom, works great and no issues for any browsers. And yes, I did use CSS to make the look of the table correct. A bonus is the mobile version of the site looks perfect since tables are easy things to get correct in even the crappiest mobile browser.
So, my lesson is sometimes it’s not worth ripping things apart when the simple solution is available.
AWSOM Pixgallery performance tuning
WordPress is a very powerful content management system. The cost of this power can sometimes be at your server’s CPU and memory resources. One tip for anyone using AWSOM Pixgallery, and NOT using it’s built in lightbox effects, is to simply turn off it’s usage of the built in effects library. This setting is in the Pixgallery admin settings/options page and is listed as “If you want to use a 3rd party javascript plugin and turn off the built in system, set the following setting to “custom” and input the custom rel code needed to add the effect to your images in the following box.”
What you are doing is turning off the loading of pixgallery.js.php, which can easily cut down on your file transfer amounts as well as overall server cpu/memory resources.
I’ll post more tuning tips over time for my plugins, as well as general ideas for overall speed/resource tuning for WordPress.
AWSOM Pixgallery updated to 4.5.10
The AWSOM Pixgallery WordPress plugin has been updated to version 4.5.10 to fix a few minor bugs dealing with the Visual Editor function as well as some pathing issues with the CSS and JS files. Nothing major but still a good idea to upgrade to stay current. You can now use the WordPress automatic upgrade function to update the plugin, so this makes it even easier.