Menu

The Customizer is one of the least known yet most powerful features of WordPress. We need to get past thinking of it as the “Theme Customizer” which only good for tweaking colors and a limited number of settings. No, the Customizer provides a framework for live-previewing any change to WordPress.

In WordPress 3.9 I led development of incorporating Widget management to the Customizer, and I’d like to get on a soapbox to get people excited about developing their own custom controls for the Customizer.

With the Front-end Editor using the Customizer as a framework, I wonder if the interface will look similar to this experiment? I hope not.

This plugin is really a prototype to demonstrate how the Customizer can be used to preview changes to posts/postmeta at an architectural level. Hardly any consideration has been given to UI, which Avryl has been doing a great job with in her Front-end editor.

Ultimately, I’m interested to see how the Front-end Editor comes into play when previewing a post or writing a draft post. Will we be able to use it to write a post or will the editor be refrained from use until after a post/page is published?

You can use this Customize Posts plugin to edit drafts as well. Just create a new post post, save a draft, and then click Preview. You can then click Customize in the admin bar to then access that post from the Customizer and you can make changes, including transitioning the post draft to a published post. This relates to a previous prototype I worked on in the Customizer Everywhere plugin, which replaces the “Preview” button with a “Preview & Customize” button.

In this case and as I’ve seen mentioned already, editing should be done inline and not with boxes popping up around the content.

In terms of a prototype which demonstrates how inline editing can be added to the Customizer, see my other prototype: Customize Inline Editing.

On a site for a newer X-Team client, APC was previously chosen as the object cache plugin. This has caused some headaches due to APC not being available while in CLI mode, rendering WP-CLI mostly broken: any commands which change parts of the database which get object-cached won’t appear until the cache gets invalidated, which may not happen anytime soon. For example, plugin (de)activation is broken in WP-CLI with APC Object Cache, as the manifest of activated plugins is cached.

Today I encountered a more serious problem with APC Object Cache.

I was making some widget changes, and I saw that my changes weren’t being reflected on the frontend. Upon reloading the widgets admin page, I also noticed that my changes didn’t seem to get saved. But if I ran wp option get widget_text, I could see my changes had been written to the database (as, of course, WP-CLI here was bypassing the APC object cache). So for some reason, APC was refusing to invalidate widget caches. Doing some more digging, I was shocked to see that the the Text widgets used in the sidebar, had multi-widget instance numbers surpassing 560,000,000. That’s right, 560 million. The output of wp option get widget_text included:

Some plugin must have at some time bumped that widget instance number up, because there’s no way there have been millions of Text widgets used on the site. Only a couple dozen Text widget instances are currently present.

In any case, this incredibly-sparse PHP array seemed like a good candidate for what was causing APC cache to fail. I swapped out APC for Memcached Object Cache, and the problem went away. While the Memcached plugin stores arrays as serialized strings, just as they get stored in the options table, the APC plugin is apc_store’ing the array wrapped in an ArrayObject instance:

if ( is_array( $data ) )
$store_data = new ArrayObject( $data );

While I couldn’t reproduce this problem on VVV or on the site’s staging environment, for some reason on production this array object failed to get stored by APC.

I’ve never had any issues with Memcached Object Cache, so I’m glad I made the switch. Not only did it fix this strange widgets issue, but it’s great to be able to once again rely on WP-CLI!

I have a few webcams on my network which I can access via URLs like http://198.162.1.30:8080/cam.jpg. Here’s a handy little bookmarklet (pagelet?) which allows you to turn any such webcam URL into live video (here, 1 fps):

Paste this data: URL into Safari and then turn it into a Dashboard widget via File > Open in Dashboard. Now you have a video Dashboard widget for your webcam! (Of course you could create a standalone HTML page and load it instead, but data: URLs are cooler and easier!)

WARNING: This could get interpreted as a Denial of Service (DOS) attack if you point this at a URL on a public web server. So it’s best to only do this for cameras on your local network.

Of course, if your camera supports MJPEG aka server-push (multipart/x-mixed-replace), you should just reference that MJPEG URL directly without any such code above.

I ran into a problem recently where I was no longer able to upload a file via PHP. I checked the server error log, and I saw entries like:

ModSecurity: Input filter: Failed writing X bytes to temporary file

Looking at my /tmp directory it contained 128MB of data. Apparently ModSecurity tries to prevent the filesystem from being maliciously filled up.

If you try to manually clean up just with a rm -rf /tmp/*, it will fail because the files are owned by dhapache and are not writable by anyone else. But, with DreamHost VPS, you have the ability to add admin users (aka sudoers). As an admin user, you can then set up a cron to automatically clear out the /tmp directory of old files:

su myadminuser
sudo crontab -e

Then in the editor which opens, add this line:

0 0 * * * find /tmp -mtime +5 -exec rm -rf {} \;

This will delete all files under /tmp which haven’t been modified in 5 days; it will happen every day at midnight.

Posts navigation

Note that our WordPress team within X-Team has formed our own sister company now distinct from our mates at X-Team International. We called ourselves X-Team WP, or now more concisely XWP. As part of this rebranding we're moving from x-team-wp.com to xwp.co, but the process is not complete yet. Pardon the dust!