Inspirated

While I run my blog at inspirated.com, I aggregate posts related to coding at the subdomain code.inspirated.com. The websites are run through WordPress and CMS Made Simple respectively.

For the latter, I needed to find a way of fetching blog posts from the main site for linking. Initially, I used tag feeds for this purpose. That is, I used the RSS module for CMS-MS and fetched the feed for a particular tag (e.g., inspirated.com/tag/code/feed). This worked well for a while until the feeds became large and I noticed that only the most recent 10 posts were showing up in the listings.

Digging around, I found this piece of documentation which explains how one can use custom queries for collecting WordPress posts from a blog. There was a catch however as the code for doing so could only be run globally. In other words, if I tried running the code mentioned on the page inside a User Defined Tag in CMS-MS I would get strange errors.

The solution was to run the code in a separate PHP file. Here’s how:

1. Create a file named wp.php in your CMS-MS folder with the following code:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

   <?php require_once('/path/to/wordpress/wp-blog-header.php'); // edit the path in the line above to point to your wp-blog-header.php   $tag = isset($_REQUEST['--tag']) ? $_REQUEST['--tag'] : 'code'; $count = isset($_REQUEST['--count']) ? $_REQUEST['--count'] : '-1'; $after = isset($_REQUEST['--after']) ? $_REQUEST['--after'] : '1970-01-01';   function filter_where($where = '') { global $after; $where .= " AND post_date >= '".$after."'"; return $where; } add_filter('posts_where', 'filter_where');   query_posts('tag='.$tag.'&posts_per_page='.$count);   echo "<ul>"; if ( have_posts() ) : while ( have_posts() ) : the_post(); echo "<li>"; echo "<a href=\""; echo the_permalink(); echo "\">"; echo the_title(); echo "</a>"; echo " ("; echo the_time('F jS, Y'); echo ")"; echo "</li>\n"; endwhile; else: echo "<li>No posts found</li>\n"; endif; echo "</ul>";   wp_reset_query(); ?>

   <?php require_once('/path/to/wordpress/wp-blog-header.php'); // edit the path in the line above to point to your wp-blog-header.php $tag = isset($_REQUEST['--tag']) ? $_REQUEST['--tag'] : 'code'; $count = isset($_REQUEST['--count']) ? $_REQUEST['--count'] : '-1'; $after = isset($_REQUEST['--after']) ? $_REQUEST['--after'] : '1970-01-01'; function filter_where($where = '') { global $after; $where .= " AND post_date >= '".$after."'"; return $where; } add_filter('posts_where', 'filter_where'); query_posts('tag='.$tag.'&posts_per_page='.$count); echo "<ul>"; if ( have_posts() ) : while ( have_posts() ) : the_post(); echo "<li>"; echo "<a href=\""; echo the_permalink(); echo "\">"; echo the_title(); echo "</a>"; echo " ("; echo the_time('F jS, Y'); echo ")"; echo "</li>\n"; endwhile; else: echo "<li>No posts found</li>\n"; endif; echo "</ul>"; wp_reset_query(); ?>

2. Add a User Defined Tag in CMS-MS with the following code:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   $path = 'whoami | php -q /path/to/wp.php'; // edit the path in the line above to point to the wp.php created in previous step   // whoami command piped for no reason because my script wasn't // producing any output without it   if(isset($params['tag'])) { $path .= ' --tag='.$params['tag']; }     if(isset($params['count'])) { $path .= ' --count='.$params['count']; }   if(isset($params['after'])) { $path .= ' --after='.$params['after']; }   echo `$path`;

   $path = 'whoami | php -q /path/to/wp.php'; // edit the path in the line above to point to the wp.php created in previous step // whoami command piped for no reason because my script wasn't // producing any output without it if(isset($params['tag'])) { $path .= ' --tag='.$params['tag']; } if(isset($params['count'])) { $path .= ' --count='.$params['count']; } if(isset($params['after'])) { $path .= ' --after='.$params['after']; } echo `$path`;

3. Use the tag in any CMS-MS page with any of the following combinations:
   • List all posts with the tag code:

     {wp_posts_with_tag tag="code"}

     {wp_posts_with_tag tag="code"}

   • List 10 posts with the tag code:

     {wp_posts_with_tag tag="code" count="10"}

     {wp_posts_with_tag tag="code" count="10"}

   • List all posts with the tag code after May 1st, 2009:

     {wp_posts_with_tag tag="code" after="2009-05-01"}

     {wp_posts_with_tag tag="code" after="2009-05-01"}

Custom queries are very powerful once you get them working. Anyone planning on using them should take a look at the function reference for getting to grips with the flexibility they offer.

Update: The virus seems to have affected only GoDaddy websites, hence the change in title.

Few hours ago I opened my website and noticed some rather strange Javascript hanging around the bottom. After some inspection, it became evident that every page on my blog was trying to load an IFrame to some place called ninoplas.com. Turns out, I wasn’t alone and there are other users as well who are affected by this. Judging by the fact that different blogs were attacked at the same time, this was in all probability the result of a security hole in some plugin or the core itself.

The virus acted by adding a piece of encrypted code on the first line of all PHP files on the server. It’s rather unsettling to consider the extend of damage that could have been caused with the write access to those files. Still, the damage could be rectified by simply deleting those lines. I wrote a tiny script for doing this job which cleans the ninoplas virus from all the PHP files in the current directory:

clean-ninoplas.sh

Warning: While this script has worked for me, I am in no way providing any guarantee for how it behaves on other blogs. Backup your blog as well as database before executing this script.
You have been warned.

Using the fix is a simple matter of:

-bash-$ cd wordpress
-bash-$ wget https://inspirated.com/uploads/clean-ninoplas.sh
-bash-$ sh clean-ninoplas.sh

And don’t forget to backup everything again after cleaning up. The security hole — if there is one — has still not been tracked and if it’s in the core or some plugin which you’re still using, the virus might not be so benevolent next time.

While starting this blog back in 2007, I didn’t care much about the URL being redundantly long in form of https://www.inspirated.com/wordpress/. Truth be told — being the lazy bum that I am — I didn’t want to go through the administrative troubles of updating the site structure to have something brief. That is, until today. As I was registering this blog as my OpenID at Slashdot I really got fed up with the sub-directory being part of my claimed identity. The result of this major aggravation was a regular Apache nutjob. First of all, I followed the instructions on this page. Then, I put together a quick .htaccess rewrite to ensure that old addresses (e.g. /wordpress/anything) still get permanently redirected to new ones (i.e. /anything):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*wordpress\/(.*)$ \/$1 [R=301,L]
</IfModule>

And just as everything seemed to work perfectly, the fgallery plugin insisted on ignoring the new URL. Digging up a bit, the culprit turned out to be a bug in fgallery‘s implementation which constructed gallery links with the WordPress address instead of the Blog address (the difference is critical in installations such as mine where WP’s core files resides in a subdirectory but the blog uses root directory for friendly URLs). The fix was trivial (had to replace a few get_bloginfo('wpurl') calls with get_bloginfo('url') instead), and lo and behold! Everything’s functional again. I should have done this little exercise a long while ago but well, better late than never. As a sidenote, this does not mean that I am reconsidering my slothful position on other pending tasks for the blog. Since for most of them I adhere to Georgy Shaw’s version of the quote instead, i.e., better never than late.

A little while ago I had to code a few fixes for the fGallery WordPress plugin. The patch was released as version 2.4.1-1 and it wasn’t until yesterday that I noticed the “Previous” and “Next” links behaving erratically for my images. Fixing it required a little hair-pulling dance with SQL sub-queries. Anyhow-way, the end product does work as expected. Here’s the incremental diff with the bugfix which should be applied to the 2.4.1-1 release. If you don’t understand what was just said in the last line, you can use the already patched zip archive to have things automatically sorted out.

For the past two years, I have been using Fredrick Fahlstad’s fGallery plugin for managing images in my WordPress blog. Unfortunately, this excellent piece of software was left unmaintained with the last stable release taking place way back in 2006. For a while now, I’ve had my gripes with some of the things in fGallery. The two options I had were to either (A) fix what was broken or to (B) use another plugin from WordPress Extend.

(B) seemed like too much trouble so I decided to go for the former option and get my hands wet with PHP again. Here’s a list of stuff that I modified in the original 2.4.1 release:

• Fixed output of special HTML characters in album and image titles to conform with XHTML standards.
• Modified to send HTTP response “Status:200 OK” back to the client in fim_photos.php. Without this, all of my fGallery pages were returning 404 error code for nice URLs even though they were working in the browser.
• Fixed an SQL injection vulnerability in fim_rss.php.
• Fixed image order on album pages and RSS feeds. Without using the table name in the ORDER queries, images were being returned in random order.
• Fixed date issues in album RSS feeds.
• Images are now shown in their original sizes in case their width is smaller than 600 pixels. In case they overflow this limit, they are shown in a 600 pixels wide frame with an option to click them for viewing in original size. This was to prevent larger image from messing up blog themes.

Here’s a diff file with the mentioned changes, which should be applied to the 2.4.1 release. I’ve also uploaded a modified zip archive for convenience of those who don’t have access to the patch command.

Today, I woke up to find that my FeedBurner feed for Inspirated has stopped updating because the source feed is timing out. After digging around a little, the source of the problem turned out to be long posts containing (hundreds of lines of) code.

At this point, I could change settings in WordPress to display “summarized” texts instead of full ones in my feeds. The downside of which was the fact that it would require readers to click through their feed aggregators even for posts that weren’t long enough to cause server delays. The better solution was to use the wp-cache plugin so that WordPress wouldn’t have to “process” the feeds at each request. The plugin itseld works like a charm, but getting things working again with FeedBurner was a bit of PITA. Here’s the order of steps that worked:

• Disable the FeedBurner FeedSmith plugin in WordPress administration panel.
• Access the original feed to make wp-cache do its magic.
• Resync the feed in FeedsBurner administration panel.
• Enable the FeedSmith plugin again.

It took me almost a couple of hours to sort out the whole picture, and ironically, one of the songs in my playlist at the time had lyrics that I’ve quoted in the post-title.

Things are finally in motion. I’m keeping my fingers crossed as I’m going to submit an application for a project based on the very same blogging engine that runs this site i.e. WordPress. My aim would be to implement an easier and efficient upgrading system in WP’s administration dashboard. I will submit my application within the next few days and keep updating my blog with its status.

Quite ironically, the news of GSoC’s opening reached me on the very same day of my web-hosting company losing all my blog posts and videos of the last three weeks. Sometimes it’s confusing when you receive good news immediately after an extremely bad one. Nevertheless, let’s hope that the good one becomes even better on 9th April — I’ll have plenty of stuff to blog about if it does.

Finally, Inspirated.com is up and running. Without further blabbing, let me list the things that are going to be different from my previous home page (Ultimation):

• Name and design.
• Obsolete source codes and references are removed. No one was interested in them anyway.
• Blogging is now done through WordPress. This will not only make the job hell lot of easier for me but will also enable other people to post comments on anything.
• Instead of a single-person effort, the site is now managed by two people i.e. me and Angeousa Quicksilver. AQ is a multimedia artist and Inspirated will hopefully be featuring his work (graphics & music) soon.

Other than that, things like my photo galley and wallpapers were just duplicated from Ultimation without any considerable difference. I’m still a bug and the Earth is still a giant monolithic kernel. See you later!