Categories
WordPress

C64 fans will like this theme

If you’re a fan of that strikingly handsome and powerful computer, the Commodore 64, you will no doubt be itching to try this Commodore theme for WordPress. It turns your blog into what every C64 owner saw when they powered on the computer. I’m disappointed it doesn’t retain the 40 character line but I guess some exceptions had to be made “in the name of progress”. We didn’t have Youtube back then either but if we did you can be sure it would be full of dodgy VHS copies of Glenroe and Cheers.

Of much more interest to a certain demographic would be a WordPress theme that embeds blog posts in an Amiga intro or C64 intro using HTML5? Someone will read a DYCP version of this post, right?

(Thanks Ian for the link!)

Categories
WordPress

Search more Twitter with Tweet Tweet

My Tweet Tweet plugin hasn’t been updated in a while. It stores Twitter conversations in your local database. Not just your own tweets but also the tweets of those you follow.

Storage can be a problem once the plugin has been running for a few months however. The log table gets quite big so last year I added code to the plugin that broke up those tables once they reached a predetermined size. In my case I go with 100,000 rows. I have over 20 of those tables now (some in an old database I haven’t copied over yet) and until today the search function in the plugin only searched the most recently created table.

All that’s changed now. It’ll search back through the other tables and compile a list of up to 10,000 tweets. It’s still a little rough but if you’ve been running the plugin for some time give the development version on the developers page a go. Here’s a search for Aurora. The original image was 21793 pixels high, so this is the latest and earlier tweets in that search:

aurora search on twitter

aurora search on twitter

Categories
WordPress

WP Super cache 1.1

This is a bugfix release of the full page caching plugin WP Super Cache for WordPress.

Not much has changed in the week or so since I asked for testers but in case you missed that post here are the changes since 1.0:

  • Use $_SERVER[ ‘SERVER_NAME’ ] to create cache directories. No more non existant blogs appearing in your cache supercache and blogs folders.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on “page on front” sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a “Cached” column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.
  • Removed debug level from logging as it wasn’t helpful.
  • Removed mention of wp-minify.

As ever, the support forum is the best place to go for help as I monitor it all the time. Before you post there use Google to search for any error strings and use the debug system in the plugin as it will probably tell you what’s going on.

Categories
WordPress

Fatal error: Allowed memory size of 67108864 bytes exhausted

WordPress uses memory. Plugins and themes use memory. New versions of software may use more memory than before. When that happens and PHP on your server doesn’t have enough memory then PHP will stop with a fatal error like this:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 1203208 bytes) in /home/*****/public_html/wp-admin/includes/class-pclzip.php on line 4215

This happens quite a bit but it’s not a bug in WordPress or your new plugin or theme, you simply need to let PHP use more memory on your server. Thankfully WordPress makes it easy to do this. You must define a constant, WP_MEMORY_LIMIT in your server’s wp-config.php like this:

define(‘WP_MEMORY_LIMIT’, ‘128M’);

The error message will give you an idea of how much memory is required. The error message says it tried to allocate 1203208 bytes or just over 1MB of memory. The limit here is 67108864 bytes, or 65536KB which is 64MB so here I’d need a WP_MEMORY_LIMIT of more than 66M. The error message will go away once PHP has enough memory but be sure to test it.

If you allocate too much memory your server could start eating into disk swap space. Also be aware that each Apache child process is allowed to use that much memory so if you had ten processes it could use ten times the memory limit in a worst case scenario. If that happens you’ll need more RAM or you’ll have to figure out what’s using so much memory.

There’s also a WP_MAX_MEMORY_LIMIT constant. By default it’s 256M and it’s currently only used when uploading images.

On the off chance that you don’t have WordPress installed and you came here from a search engine, then you’ll want to use ini_set() somewhere early in the PHP process to increase the memory limit:

ini_set(‘memory_limit’, ‘128M’);

Finally, I love that the wp-config.php codex page is the first result of a search for WP_MEMORY_LIMIT.

Categories
WordPress

Super Cache for the Weekend

WP Super Cache 1.0 came out several months ago and while it worked fine for most people there’s always room for improvement and bug fixes. Here are some of the bug fixes and improvements coming in the next version which I plan on releasing next week.

There are a lot of changes there so if you have a self hosted blog I would really appreciate if you download the development version, wp-super-cache.zip and install it in your plugins folder.

  • Use $_SERVER[ ‘SERVER_NAME’ ] to create cache directories.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on “page on front” sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a “Cached” column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.
Categories
WordPress

Wikipedia Irish Style

WordPress on Mickopedia via r/Ireland.

Categories
WordPress

AutOptimize Me!

Testing out AutOptimize here. It minifies html and css and then Super Cache caches the optimized code. Hopefully won’t be any rendering surprises.

Oh, hi from Iceland!
image

Categories
WordPress

And my first WordPress.org post was …

My post on this forum thread was my first one on WordPress.org apparently.

It was 8 years ago and WordPress didn’t have a plugin system and wouldn’t have until later. I had integrated Smarty into the b2++ project, with a nifty versioned template editor and even looked at doing the same with WordPress. Smarty had a plugin system that could be used in theory but nothing came of it.

What was your first post on the WordPress.org forum? Look in your profile to find out!

Categories
WordPress

A cache directory is a temporary directory

WOAH! Do not put symlinks to your uploaded files in a temporary cache directory. Nginx users running WordPress should beware if they followed these instructions and put a symlink to uploaded files in the wp-content/cache/ directory. I’m going to rewrite that page right now suggesting they use a different directory, possibly wp-content/uploads/ or maybe wp-content/files/.

WP Super Cache (and I presume other caching plugins) will delete everything in the cache directory. It’s like putting important files in /tmp/ where files are routinely cleaned out on reboot.

My replies on the thread above might paint me as a cold heartless bastard but I am sorry those websites suffered data loss. However I’m shocked that they put links to uploaded images in a folder containing temporary files!

Edit (20 minutes later): the codex page has been updated, thanks Westi for your help. It now recommends using wp-content/ms-filemap/ rather than wp-content/cache/

Categories
WordPress

WP-Super-Cache: bug fixing and PHP object destruction

If you use the WPTouch mobile plugin, or the preload function in my caching plugin, or noticed that annoying but random and (thankfully) rare “front page isn’t showing my front page” bug then you might like to try the development version of WP-Super-Cache located on this page.

Mobile plugins need to tell WP Super Cache what user agents they support. I documented the filters you can use (“cached_mobile_browsers” and others) to do this but I don’t think they’ve been used by any plugin. It’s not hard to do and I added code that checks for WPTouch so when you visit the WP Super Cache settings page it updates the mobile user agents. So far it works for me but please feel free to view this site on your mobile phone and tell me if it looks ok! I also added support for the theme switcher in WPTouch based on code posted on the wporg forum.

It appears that the “random post on the front page” problem is a side effect of how PHP works. WordPress incorrectly reported that the current page wasn’t a search page, even though it was. I put an extra bit of code in checking if $_GET is non empty and that fixed it, so far.

Just in case anyone else is interested, this is why is_search() fails randomly when run during PHP shutdown. When a PHP process shuts down it starts by killing off objects. Unfortunately this happens before PHP stops executing your code, something that changed after PHP4.

Anything that runs when the output buffer finishes or that is registered by register_shutdown_function() better not depend on objects or classes. That means no using $wpdb, the object cache may disappear or to be completely paranoid don’t expect $wp_query to be around either! The functions is_search(), is_feed() and other related WordPress functions depend on $wp_query so you should cache the values of those functions earlier in the process. I’m thinking of hooking into wp_head but that depends on the theme unfortunately. Not every theme uses that action.

Many years ago I changed the format of the cache “meta file” from an object to an array because of the way the PHP desctruction process works. More recently, but still two years ago I had to remove all calls to get_option() and update_option() in the output buffer handler because occasionally people saw the error, “Call to a member function get() on a non-object in cache.php” in their error log. The object cache object had been destroyed by PHP! That was a right pain to figure out as the code looked perfect yet didn’t work right some of the time.

To help figure out problems I’ve added a lot more debugging to the plugin too. If $wp_query disappears it’ll appear in your debug log, and preloading will generate a lot more messages now.

Next up is caching is_search(), is_feed(), is_single() etc. Where should those be cached? The “init” action is too early for is_search and probably others but I don’t want to depend on actions that may not be in a theme.