WP-phptidy – a tool to clean up WordPress plugin and theme code
What is it?
WP-phptidy is based on phptidy, by Magnus Rosenbaum. Eoin Gallagher made some adjustments to phptidy (2.9, circa November, 2009) so that it would better conform to the WordPress PHP Coding Standards, which are similar in most respects to at least one set of PEAR Coding Standards.
Silviu-Cristian Burcă (aka scribu) kindly placed Eoin's work on github in January of 2012. As I have a natural aversion to social media and github's quasi-social media paradigm, I chose not to fork the project there, but rather to pull it and put it in my own Subversion repository, hosted on my server, and to make my changes freely available to others. Code contributions and patches are most welcome.
Where to download it
The latest build is available via anonymous FTP from my server. I presently do not allow access to my Subversion repository, and I have not yet added this project to my Mantis bugtracker (though I will be sure to update this support page if and when I do).
Requirements
From the phptidy readme:
- PHP 5
phptidy does not work on PHP 4, because some functions introduced in PHP 5
are used, and there are also some differences in the tokens. But it should
be not too difficult to port it to PHP 4.- PHP CLI SAPI
http://php.net/manual/en/features.commandline.php
phptidy expects PHP in /usr/bin/php. If your PHP executable is in a
different path, you will have to edit the first line of phptidy.php.- PHP extension: Tokenizer
http://php.net/manual/en/book.tokenizer.phpOptional:
- diff
The standard Unix diff utility or similar
Default is to use colordiff.
Only required if you want to use phptidy's "diff" command.- PHP extension: mbstring
http://php.net/manual/en/book.tokenizer.php
Only required if you want to use the configration variable $encoding to
check the encoding of your PHP files.phptidy should work on most operation systems where PHP works.
Operating system compatibility
Out of the box, WP-phptidy should run on any platform capable of running phptidy (see above). I am also taking steps to ensure compatibility with OS/2.
How to use it
Unzip the contents of the zip (single directory) wherever convenient. Running WP-phptidy with no arguments yields a brief syntax reference:
Usage: phptidy.php command [files|options] Commands: suffix Write output into files with suffix .phptidy.php replace Replace files and backup original as .phptidybak diff Show diff between old and new source source Show processed source code of affected files files Show files that would be processed tokens Show source file tokens help Display this message Options: -v Verbose messages If no files are supplied on command line, they will be read from the config file. See README and source comments for more information.
I've included the original readme from phptidy as a more complete command reference, as well as the README.markdown from scribu's github submission, and my own readme and changelog. Between these references, a working understanding of the tool should be readily obtained.
My changes to the original WP-phptidy
So far, I've added/updated the following:
- Updated phptidy to 2.11.
- Added new function: fix_logical_space, which defaults to true. This adds a space after "!" in statements such as !isset, for example.
Look for these enhancements which are on my roadmap:
- Better detection of missing braces (curly brackets).
-
Space alignment for arrays, e.g.:
$my_array = array( [tab]'foo' => 'somevalue', [tab]'foo2' => 'somevalue2', [tab]'foo3' => 'somevalue3', [tab]'foo34' => 'somevalue3', );
License
WP-phptidy is released under GPL v2, as is phptidy. A copy of the license is included in the distribution.
Working around the broken RSS feed code in Joomla! 3.2
I'll probaby backfill some more tips & tricks I've picked up this past week, during an upgrade of a client's site from Joomla! 1.5.22 to 3.2, but in the meantime, as this seems to be a nagging bug (well a collection of them; not necessarily a swarm or even a hive, but a colony, nonetheless), I figured I should get something posted about it to hopefully save someone else an hour or two of poking (and testing modules to just replace the built-in feed module, anyway).
WordPress, WooCommerce, and the elusive WP_MEMORY_LIMIT issue
WooCommerce (and likely some other WordPress plugins - and non-WordPress apps - tend to be rather microcosmic when determining system settings. Case in point: the PHP memory limit.
Prior to PHP 5.2.1, the per-script memory limit available was set at compile time (via the --enable-memory-limit option). With 5.2.1, we got the php.ini directive:
memory_limit <integer>
to set this value at run time 1. In fact, it can even be overridden (if the server admin allows) so that specific apps may set it themselves, thus allowing for greater granularity across all running PHP applications on the server, even under the same instance of the engine.
- http://www.php.net/manual/en/ini.core.php#ini.memory-limit ↩
Updating the TCPDF library in Joomla! 1.5
TCPDF is an excellent PHP class for creating PDFs from dynamic (or static, for that matter) web content. Unfortunately, the version of TCPDF bundled with Joomla! 1.5 (all 1.5 releases after at least 1.5.8 - someone please correct me if I am wrong - was version 2.6.000_PHP4, dated March 7, 2008. It's also not very PHP 5.3-friendly (there are other parts of Joomla! 1.5 which are not fully compatible with PHP 5.3, but this article will focus on TCPDF). Time to freshen up, methinks.
Mass editing users in WordPress
Eek!
A thousand apologies to those of you who have received email notifications of my last post, which added two new categories to the blog. Following up on an enhancement request from a long-time friend to provide email notifications of new posts, I installed the Subscribe2 plugin. Not fully understanding the ramifications of setting "Option for Registered Users to auto-subscribe to new categories is checked by default" to "Yes," I set that, which automatically enabled all existing users as subscribers to newly-created categories, even if they were not subscribed to any categories previously (my reading of this option was that only new registrants would be auto-subscribed to new categories, thus saving them click-time during setup).
Mantis email fun – part 2
Well, this is embarrassing... I can't believe I started this draft back in January (of 2012), and let it sit so long. Sorry about that...
You may read up on my involvement with a particular Mantis Bug Tracker installation in part 1 of this series. This time around, I'm going to discuss adding the ability to discourage email recipients from replying to bug update announcements.
Mantis email fun – part 1
Mantis Bug Tracker is a great tool. Several friends use it (I was originally going to set up Bugzilla, as I'd had more experience from a user's perspective with it, during my years of submitting and contributing to Mozilla issues), and I finally got my chance to sink my teeth into it in 2009, when I took over the web hosting for OS/2 VOICE. In that instance, I inherited a well-oiled machine, so I had no real need to dig too far into the initial setup routines for the app.
Several months ago, I upgraded that particular installation, and set one up for myself. Naturally, as these things go, "setting one up" and actually "putting stuff into it" are two entirely different things, so until last week, when I really felt the urge, I didn't have any real chance to play with my new install.
So it was that last week I decided to check out where I left off and get an existing small project into it. (Eventually, I'll get fancy and incorporate Subversion or GIT into the Mantis setup, but for now, I just want to organize all of my electronic sticky-notes, so that I can make sense of what I've got and what I need to do moving forward). My first hurdle was that I couldn't for the life of me recall what my password was. Nothing seemed to work, and naturally, I hadn't stored it in SeaMonkey or Firefox or my other password keeper. Unperturbed, I clicked the link to send the password reset request. Nothing happened.