disableMUWell, there’s nothing like quickly pushing an update after your initial release! After all the initial testing that went into the version of DisableMU which I submitted to the repository, it turned out there was a severe failure in the logic used when determining where to inject the Constants which I needed to override with the plugin.

Due to the fact that wp-settings.php is included just before the end of the file, that was in turn including default-constants.php which defines the values of the /mu-plugin directory & url. That meant that by the time WordPress got to my definitions… it ignored them.

This meant no harm was done by the installation of the plugin, but it also meant that nothing was effectively happening by using the plugin! Initial tests to confirm the value of the Constants were done prior to the final coding which injected at the end of the file, which just goes to prove that you should always check your work! No matter how confident you are in it, each change you make in the development process has the potential to have unexpected consequences.

Go download version 1.1 from the repository now!

disableMUYesterday, my first plugin was approved and released within the plugin repository on wordpress.org. Woohoo!


Most of the relevant information can be found on the repository page or on the DisableMU page here on the site. Long story short, I wanted a way to protect my sites from malicious code being uploaded to the /wp-content/mu-plugins directory in the event of a server compromise or malicious plugin code executing.

The way the plugin works is by tricking WordPress into not being able to find the intended path to the mu-plugins folder. This can (and is) accomplished by defining three Constants inside of wp-config.php

The only difference is, using DisableMU removes the need for you to touch your own wp-config.php file and that the final directory path is randomly generated each time the plugin is activated. This means that no two installations are running the same “renamed” directory.

Hopefully it helps you, and let me know if you have any feedback!

With the rebirth of Binary Templar, I knew I would need a way to publish code to my posts. Syntax highlighting was obviously a must, and ease of use was very far and away at the top of my list. I tested a few plugins, most based on GeSHi, before stumbling upon Crayon.

Crayon has a TON of features but boils down to a plugin that does its job and does it damn well. Once I played around with the numerous options for defaults, I finally got things to where adding code to a post is a single mouse click away inside the Visual Editor.

I can customize the look and feel if I want on a per-use basis, but why mess with a good thing? Out of the box it supports line numbers, syntax highlighting (there are easily 20 themes to choose from, just like most development IDE’s, and you have the ability to quickly create your own as well), copy abilities – I’m having a hard time finding features that it doesn’t have. Oh, and it even has the ability to highlight particular lines if you wish, as well.

I’m looking forward to playing with Crayon more as I continue, but if anyone out there has other suggestions for a plugin that they would recommend as an alternative then leave a note in the comments!