I’ve been out of the WordPress loop for a little while now and I’m not up to speed to what some of the new developer oriented hotness is that could be added to the bundle so if you’re looking for something in particular drop a comment here or open an issue on GitHub.

If you’re so inclined go ahead and Fork it, update what you need and submit a pull request. Since I don’t work with WordPress on a regular basis there are going to be those of you out there that have a better grasp than I on what should be added, or even what should be removed, from the Bundle.

So, my apologies for the delay with the update. I’ll try not to let it happen again.

So, there it is. TextMate 2 Alpha support. If you notice anything weird please open a Support Ticket on GitHub. Please include the full text of the error that you receive as that’ll most likely be what I need to fix the problem.

WordPress 3.3 support is hot on its heels. Really!

I’ve been doing some cursory testing with the WordPress Bundle and so far it appears that only a few minor modifications might be needed to be compatible.

Better yet, though I haven’t fully tested this yet, the changes should be backwards compatible with TextMate 1.5. For the time being it doesn’t appear as thought I’ll have to create a branch just for TextMate 2.

So, keeping in mind that TM2 is Alpha, I’m pleased with how things are panning out. I’m eager to get in to the guts the new bundles and figure out what more I can do to make the WordPress bundle even better (suggestions are welcome!).

Congratulations to Mr. Odgaard on his release. I hope he’s able to ignore the petty jerks who keep harassing him and finish up what already looks to be a kick-ass upgrade.

These helpers are designed to help give consistently formatted output no matter where they’re used. They output specific styling inline to override the current site’s style sheets and output readable, monospace formatted code in most scenarios.

The pp() & dp() functions output to screen and the ep() function outputs to the error log.

Install

Copy the code above, or copy from the Gist File. Paste the contents in to a file that is accessible to your web-server software. Next, edit your php.ini file and edit the line with the auto_prepend_file setting with the full path to your helper file. Now restart apache to reload the php.ini.

Usage

All methods will output simple scalar values in their normal format and will translate boolean values to their string values instead of their numerical values. Object and arrays are then run through either print_r() or var_dump() depending upon which method you use.

In general pp() will give you the most readable output as it uses print_r() to output. But one drawback of print_r() is that it doesn’t tell you what type the variable is. This can be a drawback if you’re working specifically against boolean or null types. In that case you can use the dp() method which uses var_dump() to output. var_dump()‘s output is less easy to read, but it does output the variable types which is very handy.

The ep() method outputs to the PHP error log. Handy for inspecting data in ajax or api calls or when outputting data is either inconvenient or hard to access.

All functions can be overloaded to take as many arguments as required. Each parameter is parsed separately and output comma separated.

Caveat

There’s only one: make sure that you don’t commit code that contains these function calls – others likely won’t have the same helper methods and your production server most assuredly doesn’t. There’s nothing like committing these methods and not realizing it until someone asks you why ‘dp() is undefined’. I’m actually pretty close to putting pre-commit hooks in to my version control repositories that reject any commit that has these methods in it. Its very easy to forget to strip them out first.

So, there it is. Nothing special, but I find these lil’ guys super handy. I hope you do too.

I just merged a pull request from Simon Wheatley in to the WordPress TextMate Bundle that adds the command wpsalts to generate the Security Keys for the WP Config file. The command uses the WordPress.org secret-key Service.

Very handy.

Thanks Simon!

After much fiddling, the updated WordPress TextMate Bundle is here and it has been updated with a much better function definition display. I’ve ditched the old function scraper that was an abomination of grep & regex matches and replaced it with doxygen and some ruby abomination to provide much more information about the function or method being inspected.

I’m pretty sure there’s a lingering issue with the parsing and display of special characters in the doxygen output (which I blame squarely on strange handling by doxygen) that I haven’t handled yet. There may be HTML Entities missing from the documentation here and there.

Also improved is that the function definition search is contextually sensitive. It’ll only look for methods when in object scope (ie: $object->method();) and only look for functions when in regular php scope (ie: function();). There’s also a prompt to select the method that you’re actually after when multiple matches are found.

So, as always there’s something that can be improved upon with the bundle, but its moving forward and getting better with each revision. I guess that’s something, right? RIGHT?

So, fire up GetBundles or head on over to the WordPress TextMate Bundle’s Github Page to update your bundle!

While enabling these caching settings is good for performance they’re not really good for development since both filesystem paths and interpreted code can be cached for periods of time. What made me notice was when a machine here in the office wasn’t honoring the new path to a renamed folder. The assets in this folder were all loaded via include statements using relative paths. Hard coded paths should not have been an issue, but for some reason the system kept looking for the files in their old location.

It took a while before I narrowed it down to the caching settings as a culprit. Once we turned off caching all together our changes were reflected immediately and all was right again with the world.

What you need to do

The modification is simple, its just a change to the MAMP preferences.

1. Open MAMP
2. Click the “Preferences” button or select “Preferences” from the MAMP menu
3. Click on “PHP” in the tab-bar if its not already selected
4. Change the “Cache” dropdown to be “––” so that no caching extension is used
5. Click “OK” to save the changes
6. Restart MAMP (click “Stop Servers” and then “Start Servers” once they’ve stopped)

No new features have been added yet, but this will at least jump you to the right place in the code base when needing to inspect an internal function. Suggestions for feature additions are always welcome, so lemme know how you use the bundle and how any improvements can help you use it better and I’ll see what I can do. As it always has been, the project’s source is freely available so you’re welcome to contribute as well if you wanna dive in to a little bit of Ruby code.

I know I’ll regret saying this, but one of my goals to hit during the 3.1 lifespan is a better code scrape of the WordPress core. I’ve been playing with a couple of different code scrapers/documentation engines to replace the janky regex that I’ve got going on, so hopefully I can find the time to put in to this as I think getting as much of the built in documentation to the surface as possible would be a boon to my sanity. Maybe once I’m caught up on my hackers list reading (I think I’m about 3 months behind) I might have a couple of ideas for adding to the bundle

I’m gonna sound jaded through this writeup, but I’ll get over it.

Say your plugin saves and retrieves data correctly, like this greatly oversimplified example:

You’re properly using the post-meta api and your array is serialized in the database, all safe and sound.

Now imagine your user migrates to a new host, exports a WXR and imports that WXR on their new host. Your data will break. Why? On import your serialized array is then double serialized as a string. The post-meta in the WXR is imported the same way as if the data had been saved programmatically which means it makes a trip through the function maybe_serialize. Unfortunately maybe_serialize has a bug that explicitly serializes already serialized data. So now your data is broken because your serialized array has just been serialized as a string. Don’t expect this behavior to change any time soon. The core WordPress team is too worried about breaking the functionality of plugins who have been saving data the wrong way to try and make this function work correctly. You have to safeguard yourself against its behavior.

Its not a lost cause, though, you can protect yourself by being a bit more verbose when pulling your post meta. When retrieving your post meta don’t assume that you know how its gonna come out. Yeah, it sounds funny, but its better safe than broken. Simply changing the above code by one line can help protect your data when it moves from server to server. Like so:

By wrapping the get_post_meta function call in a maybe_unserialize call you force the data coming out of the database to be inspected one more time and then double-unserialize if necessary. Its extra work but it can save your butt.

I’m not a big fan of checking every file download with WordPress as it can take a lot of overhead if you’re running a busy site. So here is a pretty straight forward way to limit downloads from a WordPress site with a minimal amount of code. In this example I’ll illustrate how to prevent non-logged in users from downloading audio files in mp3 and m4a format.

Basic Blocking

First, lets use some ModRewrite rules to get Apache to show users a 403 forbidden page when trying to access the files. This isn’t pretty, it simply gets Apache to dump the user in to a default 403 page and the user is told that their access is forbidden. The .htaccess changes:

On the first line of this code you’ll see (mp3|m4a). This is the part that looks at the ending of the file name and determines which files it will act upon. replace the items inside the parentheses with the file types that you want to protect, each one separated by the pipe character. So, for example, if you wanted to protect PDF and RTF files you’d change it to: RewriteCond %{REQUEST_FILENAME} ^.*(pdf|doc)$

That is really all we need but its not very nice to dump the user like that and not inform them of why they were forbidden. They may assume that the site is broken. So lets do this the right way and get the users redirected to a page that will inform them of why they were denied access to the content.

Redirecting the Access Denied

For this we’ll need a page template. You can create anything you’d like, but the basics of it are:

Your template will obviously look a bit different. I did this one as an extension to the new Twenty Ten theme in WordPress 3.0 and based it off of the provided 404 template.

Save the file to your theme’s directory. It doesn’t matter what you name it. WordPress will actually pick up on the Template Name: 403 portion as the template ID.

Next we need to create a page in the WordPress admin for our notification page. Create a new page, name it whatever you want. For my purposes I titled the page “Not Allowed” so my slug ended up as “not-allowed”. You can edit these to be any values you want if the page title created a slug that you don’t like. You’ll need that slug here in the next step. Next select the 403 page template from page templates select input in the Attributes meta box (typically on the right side of the page, underneath the Publish button. Publish the page.

Now let’s alter that .htacess directive to redirect to this page instead of showing that unfriendly Apache notice. The modified directives are:

The relevant change happened on the third line where the dash was replaced by the relative url to my 403 page. In my case that is /not-allowed. Yours will differ depending upon how named your page. Don’t forget the leading slash when adding your slug so that it’s a valid relative path. (This can be an absolute path as well, ie: one that contains the full http://domain.com/blah-blah but there’s no need to do that here unless you’ve got valid reason to do so, like if you want to redirect the user to a different domain).

Now, whenever someone who is not logged in tries to download a file type that you’ve specified they’ll be redirected to your 403 page. What you tell them there is up to you.

But…

…now, if you’re theme lists out pages anywhere, you’ve got this 403 page sticking its nose in where it doesn’t belong. Not very pretty, now, is it? This is pretty easily remedied. Head on in to the WP Admin and to the page edit screen for the 403 page. Take note of its page ID in the url. It will be the number after the word “post=” in the url. For example, if your URL looks like http://wp30.local/wp-admin/post.php?post=8&action=edit the post id is 8.

We now need to make an addition to your theme’s functions.php file. This file is located in your theme directory. Open this file and add in the following code:

On the line that says array_push($excludes, 8); replace the 8 with the id of the page you just created. This will keep the function wp_list_pages() from outputting the 403 page in any of its lists.

Note: if you’ve got other places in your theme that are pulling page lists through different means you’ll want to modify or filter those results as well. Depending upon the methods used to make the lists you can probably exclude the page as a parameter of the call for pages instead of using a filter. Your mileage will vary, but it is certainly doable.

Ta da!

And there you have it. Simple and straight forward. No real frills, though. As it sits now the user is redirected to a page that just tells then simply that they need to be a logged in user. That’s not very informative all by itself. There are a hundred ways to modify this to make it more convenient on the user.

Hopefully this gives you some ideas on what can be done to help legitimate users get to your content while keeping the rif-raff from poaching it.