Archive

Category Archives for "WordPress"

This site is run on WordPress. I’ve authored a few plugins, mostly for use on sites I manage for my wife and I. I’ve picked up a few tricks and learned a few things about the internals of WordPress along the way and I’ll share that knowledge in these posts.

Autocomplete Orders in WooCommerce 3.0

There’s more than one way to autocomplete orders in WooCommerce 3.0. If the products in an order are all virtual and downloadable, the order will be marked completed once payment is received. Any other order will be marked processing to indicate some manual work is needed on the part of the shop owner to complete the transaction. Most articles I found on this topic use an action hooked to woocommerce_thankyou or a filter on woocommerce_payment_complete_order_status. There is another way. A better way.

Continue reading

Implementing WordPress TinyMCE plugins for multisite configurations

Note: This discussion pertains to V3.* of WP using an older TinyMCE implementation.  Details might be different now.

WordPress Multi-site configurations often present some unique challenges for WordPress plugin authors.  One I just finished dealing with is how WordPress handles a WP plugin that is defining a TinyMCE editor plugin.  What follows is going to be very technical so read on if you want to learn more about writing TinyMCE editor plugins in a WordPress environment.

Continue reading

HowTo: WordPress Plugin Supplied Templates for Custom Post Types

While prototyping a WordPress plugin I’m writing, I experimented with supplying default templates to display pages related to a custom post type. This is accomplished using the template_redirect action API.  If the following technique is not used, any special templates a plugin provides would need to be copied to the active theme, making plugin installation more complex than necessary.

Continue reading

WordPress, mod_rewrite and mod_security

Being conscious of web security is sometimes a real pain in the you know what.  I’m seeing some attempts to directly access some scripts on WordPress sites I maintain that should not be directly accessed.  No harm is being done, but there are “500 Internal Server Error” results being generated that should instead be “403 Forbidden” or “404 Not Found”.

I’ve made a few stabs at changing the re-write rules and am now looking the mod_security rules as perhaps a better method to trap the errors.  In both cases, there appears to a lack of good tools to use for testing the rules without making them active on a website somewhere.  And this is making it more complicated of course to get the rules right!

Stay tuned…  I’ve got a few more ideas and if I get this sorted out to my satisfaction, I’ll be posting an update on some good ways to protect areas of WordPress that should not be directly accessed via browser requests.  I haven’t found much on this topic in my searches on the web.  In fact, many places I find recommend turning off mod_security for WordPress.  I had a site hacked once with a SQL Injection attack because I had followed that advice.  I’m doing what I can to prevent that in the future!

css.php