I’ve finally taken the time to learn Symfony. It really is a remarkable platform, and I’ve been meaning to pick it up for quite some time. My first project is non-pretty, at least visually, but it works well.
Go get it! In this release, I’ve deprecated the dependency on the Twig templating system. Don’t get me wrong – Twig is fantastic! However, I was only using the tiniest bit of its functionality, and it was really a heavy-handed approach to a simple problem. I refactored the code into a pure PHP alternative in maybe 10 minutes.
Having Twig exposed an issue with both WordPress and PHP (One I should have foreseen, actually). In WordPress, it can be a real challenge to have multiple copies of the same third-party library in the same install. To wit, if two plugin authors both include the standard Twig package, the second authors plugin won’t activate because Twig is already instantiated. Sure you can check to see if Twig already is declared and simply use that instance, but there’s no guarantee that they’re using the same version. If they’re using an older version and you try to use a feature included in the newer version, you’re out of luck.
Namespacing or class nesting could solve the problem. However, PHP doesn’t implement those features well enough (or at all, in the case of class nesting) to solve the basic issue. It would be fantastic to be able to open a new PHP file, declare a namespace, and require Twig, then Twig would be sitting all pretty and ready to go under my own umbrella namespace. Class collisions would be near-impossible.
My opinion of PHP, in general, has changed since I wrote my little post about PHP being web legos. If wielded correctly, PHP can be a fantastic language to work with. But occasionally you still get the feeling that OOP was sort of bolted on (and it was), and miss some of the things you get when a language is object oriented from day one.
After upgrading to WordPress 4.4 on a couple sites I manage, I noticed that some shortcodes weren’t rendering (“Rendering” is the fancy word I use to describe what happens when WordPress changes a shortcode into whatever text or code that shortcode is supposed to become). With no changes to the text in pages or posts, the shortcodes were simply being displayed in their shortcode form instead of interpreted and rendered.
Here I present an example. I have a private post on this site which I use to test my Responsive Video Light plugin. It’s simply two shortcodes – one for YouTube and one for Vimeo.
Curiously, when this post was viewed, the top shortcode would not render, but the bottom one would. It’s not a syntax problem, they’re both correctly formed, or at least appear to be. After much Google-foo, I finally stumbled across an article that instructs you to re-type any spaces in your shortcodes not working after upgrading to WordPress 4.4. I thought to myself “no, that can’t be it,” but decided to give it a shot anyway. Lo and behold, it worked!
To figure out why this was so, I reverted to the earlier, non-working version of my test post, and copied and pasted its contents into a file that I could inspect with a hex editor. My hunch was that the spaces were in fact different, but the difference couldn’t be seen by eye. Take a look at the following screenshots. This first one highlights the space between “responsive_youtube” and the video URL in the shortcode, which is the one that doesn’t render. This space is not a simple single-byte ASCII space (0x20), but is actually a two-byte sequence, 0xC2 0xA0. Google reveals that is a Unicode symbol for a non-breaking space!
In this final screenshot, the highlighted part is the space between “responsive_vimeo” and the rest of its arguments. This is a true ASCII space (0x20), and so this shortcode renders properly.
I cannot imagine why upgrading WordPress would cause this. My hunch is that some older version of TinyMCE (the visual editor) inserted the Unicode space instead of the ASCII space. Wordpress comes along and adds some Unicode support in a parser somewhere in the newest version, and now that no longer sees a Unicode non-breaking space as identical to a simple ASCII Space. Things break, nerds weep and shake their fists. Oh well. At least I know what’s causing it – I won’t dig any further into WordPress to find the root cause – I’ve spent enough time just figuring this much out. Enjoy your newfound knowledge ;-)
I’ve been threatening long enough – I finally wrapped my jQuery.autoTarget jQuery plugin into a WordPress plugin, making it super simple to make all your external links automagically open in a new tab/window. Go grab jQuery.autoTarget for WordPress!
Oh, and in the spirit of Dogfooding, I also use this plugin on this site.
In preparing to roll out a WordPress plugin version of jQuery.autoTarget (currently under review for inclusion in the WordPress Codex), I discovered that I had a slight error in the regular expression I use to extract the domain from all the links on a page. It’s not hard to have an error in a regular expression, they are dark magic after all. It also occurred to me that I was overwriting any extant targets that may be set deliberately by the site owner/developer, so I added in code to prevent that clobbering from happening.
Go download jQuery.autoTarget v1.1.0!
(Update: the WordPress plugin version of this is now up and ready for the masses!)
I just became aware of the php-fig coding standards group. After reviewing their materials, I’m implementing their recommendations in my PHP code from here out. It will be my subtle act of rebellion against the WordPress coding standards, by the way. I’d adopted the WordPress standards, but really didn’t much care for a few of them (coders can be a very finicky bunch when it comes to the utility and aesthetic of code), but agree almost wholeheartedly with the group at php-fig. Their membership includes leaders from a huge number of leading PHP projects (not the least of which are Zend Framework 2 and PEAR), and I’m convinced that they’re on the right path.
For what it’s worth, a coding standard doesn’t affect the functionality of the written code from the end-user’s perspective, so this adoption doesn’t affect you, loyal fans of my plugins and such.
I finally reached the point where I was tired of finding and copying over the same snippet of jQuery code to make external links automagically open in a new tab/window. So I wrote my first jQuery plugin called jQuery.autoTarget. Super simple to use. Next up will be a WordPress plugin to so the same thing for any given WordPress installation.
Hello all. I’ve just released Responsive Video Light v1.1.0 to address a couple of minor issues with YouTube. There’s a new set of wmode parameters and a new wmode global setting in the plugin. Check it out!
Most people use the tool called “diff” to track code changes or build patches to apply to various pieces of code. A buddy of mine introduced me to a technique of using a diff almost like a unit test, where you create a set of “green bar” (known good output) files, then make changes to your code, then run diff against the newly generated output vs your green bar files. I implemented this technique to make sure I don’t break something as I work my way through all the refactoring I want to do on boxologic’s code. Curious about how it’s done? Check out the test target in the make file and the bash script it runs.
We had a fairly nasty bug in Boxologic, where some test files would run, others would segfault, and yet others would get stuck in an infinite loop. I thought that it had to be a transcription error from when I originally moved the code from PDF format into a real buildable file. Turns out I was right, but I had to print off the appendix of the PDF that held the original source code and go through it line by line until I found it, ticking off each line of code as I went. And just my luck, it was one of the middle line in the last function of the program. Oh well. At least things are working the way they should now, and this opens up the way for more refactoring.