Version 1.1.1 of jsmin-php is now available. The only change in this release is a fix for an issue that caused excessive memory allocation when minifying very large JavaScript files.
- jsmin-1.1.1.php (7.8KB)
Posts tagged with “php”
Displaying items 1 - 10 of 16
WordPress sucks
More than two years ago, I wrote a scathing, obscenity-filled tirade about WordPress's misuse of addslashes() to escape user-supplied strings used in SQL queries.
Lots of people posted comments. Some said I was being pedantic, some said I was downright wrong, and one person linked to a diff showing a fix that was supposedly going to be in the next release.
Apparently they never got around to releasing that fix.
Ports freezes suck
While FreeBSD is, on the whole, a lovely server operating system and the ports collection was, at one time, a lovely software distribution mechanism created in an era when such things weren't at all common, the ports collection has been showing its age for quite a while now.
One of the most infuriating things about the ports collection is the ports freeze. These occur for periods of several weeks (sometimes even a month or more) during the runup to every FreeBSD release. Since ports is entirely dependent on CVS, and since, for reasons I don't understand but nevertheless find utterly baffling, the ports management team aren't willing to create a stable branch of the ports tree from which to do the release and would rather freeze the trunk, this means that there is a long, dead period when software managed via the ports collection cannot be updated through ports.
Invariably, ports freezes seem to be the time when all manner of security vulnerabilities are patched, particularly in PHP. Of course, since the ports tree is frozen, these patches can't be committed, so FreeBSD server administrators are left with the choice of waiting out the freeze and hoping nobody bothers exploiting the vulnerabilities or patching the affected software manually, which can (in the case of something as huge and with as many dependencies as PHP) be an enormous pain in the ass.
I'm not sure what malevolent entity is responsible for ensuring that ports freeze announcements are always followed by a plethora of vulnerability announcements, but I sure wish they'd stop it. It's annoying.
A faster JSMin library for PHP
I wasn't happy with the performance of the existing PHP port of JSMin, so I wrote my own implementation, which is significantly smaller and faster. This new library will be included in the next release of Minify, and you're welcome to download it and use it in your own projects:
require 'jsmin.php';
// Output a minified version of example.js.
echo JSMin::minify(file_get_contents('example.js'));
Minify combines, minifies, and caches JavaScript and CSS files on demand to speed up page loads
Web pages that refer to multiple CSS or JavaScript files often suffer from slower page loads, since the browser must request each referenced file individually. Most browsers will only make two simultaneous requests to a single server. The latency involved in opening multiple requests and waiting for them to finish before making new requests can result in a user-visible delay, and that can make your users sad.
Minify is a PHP library that attempts to fix this problem by combining multiple CSS or JavaScript files into one download. By default, it also removes comments and unnecessary whitespace to decrease the amount of data that must be sent to the browser. Most importantly, it does all of this on the fly and requires only a few simple changes to your existing web pages.
Before Minify:
<html>
<head>
<title>Example Page</title>
<link rel="stylesheet" type="text/css" href="example.css" />
<link rel="stylesheet" type="text/css" href="monkeys.css" />
<script type="text/javascript" src="prototype.js"></script>
<script type="text/javascript" src="example.js"></script>
</head>
<body>
<p>
Blah.
</p>
</body>
</html>
After Minify:
<html>
<head>
<title>Example Page</title>
<link rel="stylesheet" type="text/css" href="example.css,monkeys.css" />
<script type="text/javascript" src="prototype.js,example.js"></script>
</head>
<body>
<p>
Blah.
</p>
</body>
</html>
Minify takes about 15 seconds to download and install, has no dependencies other than PHP 5.2.1 or higher, works on any web server, and requires only minor modifications to your existing web pages. And it's free!
Visit the Minify website to learn more or, if you're already sold, download it now.
Crackup: Crappy Remote Backup
Crackup is a pretty simple, pretty secure remote backup solution for folks who want to keep their data securely backed up but aren't particularly concerned about bandwidth usage.
Crackup is ideal for backing up lots of small files, but somewhat less ideal for backing up large files, since any change to a file means the entire file must be transferred. If you need something bandwidth-efficient, try Duplicity. Crackup is a quick and simple (but secure and reliable) hack that gets the job done, but not much more. My main reason for writing it was that I needed something similar to Duplicity that would work well on both Windows and Unix systems. Crackup runs well on Windows under Cygwin.
Backups are compressed and encrypted via GPG and can be transferred to the remote location over a variety of protocols, including FTP, FTPS, and SFTP.
I just put the finishing touches on the first usable version of the backup client a few minutes ago and it seems to work well. There's no restore client yet, but it'll be easy to whip up as soon as I get around to it (which will hopefully be before I need to use it).
Update: crackup-restore is now complete and is available in the SVN repository along with the rest of Crackup. Enjoy!
MediaWiki is an ugly mess
I’ve been digging deep into the innards of MediaWiki, the software that powers Wikipedia and hundreds (thousands?) of other wikis, for a new website I’m working on. I chose to use MediaWiki because it’s one of the most featureful wikis available, yet isn’t so complex that it takes forever to customize.
Unfortunately, while it’s a nice enough application on the outside, MediaWiki’s insides are complete shit. The code is a horrendous mess, but that’s not the worst thing about it. The worst thing is that it’s a badly-architected horrendous mess.
There are places where the developers make feeble attempts to separate logic from presentation, which in many cases just ends up making things more complex, because you end up with a sort of pseudo-separation where some parts of the presentation layer are separate, while others (a lot of others) are still embedded in the logic.
For example, each section of the sidebar is defined in a completely different part of the application. One section is defined in, of all places, a language file. Another is defined in a skin template. Yet another is embedded in a PHP include deep in the heart of the application. It’s ridiculous.
I was also shocked to discover a directory named maintenance, which is included in the web root of the application and contains hundreds of command-line PHP scripts intended to be run only by administrators. One of them is named eval.php. Guess what it does?
The only thing keeping the public at large from executing these scripts over the web is an .htaccess file. That’s fine if you’re using MediaWiki on an Apache server configured to allow .htaccess overrides, but what if your server isn’t Apache? What if it’s not configured to allow overrides? I didn’t see anything in the install docs that warned me I needed to secure this directory.
Here’s a nice little snippet from MediaWiki’s default skin class, MonoBookTemplate:
<div id="p-cactions" class="portlet">
<h5><?php $this->msg('views') ?></h5>
<ul>
<?php foreach($this->data['content_actions'] as $key => $tab) { ?>
<li id="ca-<?php echo htmlspecialchars($key) ?>"<?php
if($tab['class']) { ?> class="<?php echo htmlspecialchars($tab['class']) ?>"<?php }
?>><a href="<?php echo htmlspecialchars($tab['href']) ?>"><?php
echo htmlspecialchars($tab['text']) ?></a></li>
<?php } ?>
</ul>
</div>
<div class="portlet" id="p-personal">
<h5><?php $this->msg('personaltools') ?></h5>
<div class="pBody">
<ul>
<?php foreach($this->data['personal_urls'] as $key => $item) { ?>
<li id="pt-<?php echo htmlspecialchars($key) ?>"<?php
if ($item['active']) { ?> class="active"<?php } ?>><a href="<?php
echo htmlspecialchars($item['href']) ?>"<?php
if(!empty($item['class'])) { ?> class="<?php
echo htmlspecialchars($item['class']) ?>"<?php } ?>><?php
echo htmlspecialchars($item['text']) ?></a></li>
<?php } ?>
</ul>
</div>
</div>
Notice the lovely mixture of HTML into a PHP class, as well as the complete lack of sensible formatting. This is just a tiny sample; there’s lots more.
In spite of all this, I’m still going to be using MediaWiki, because, sadly, it’s the best thing out there at what it does. That should tell you a lot about the general quality level of open source PHP applications.
PHP's developers finally learn why namespaces are a good idea
PHP is a wonderfully flexible and powerful language, but it's notorious for having a very polluted global namespace and no way to define separate namespaces other than wrapping things in classes. Users have been begging for a better solution for years, but to no avail. It looks like that may finally change, though.
The release of PHP 5.1.0 just before Thanksgiving introduced a new native Date class for (not surprisingly) manipulating dates and times. Unfortunately, PHP's developers either didn't notice or didn't care that there was already a very popular PEAR class called Date. So anyone who was using the PEAR Date class and upgraded to PHP 5.1.0 suddenly found themselves using an entirely different and incompatible native Date class, which broke hundreds, if not thousands, of applications.
The PHP mailing lists were instantly abuzz with users complaining about the breakage and developers proposing half-baked ideas for solving the problem by — at long last — introducing namespaces. Thankfully, cooler heads realized that namespaces are a big change and the most important thing was to fix the immediate problem, so PHP 5.1.1 was quickly released minus the new Date class.
This incident seems to have hammered home to the PHP team just how important namespaces are and how painful it is to try and design a language as big as PHP without them. Maybe after this they'll finally get their shit together and add namespaces in PHP 6.
I hate you, PayPal
I've been fighting with PayPal's Website Payments Pro API for the last week at work. If you're considering using PayPal for anything more than accepting basic payments through their website, here's my advice to you: kill yourself.
The documentation is disorganized, incomplete, and full of errors. The page numbers in the Website Payments Pro Integration Guide aren't even correct. Good luck finding chapter six on page 83; there is no chapter six (although there are two chapter fives), and page 83 is just a few pages after page 56 and a few pages before page 105.
If you're dumb enough to actually try to use the PHP SDK PayPal provides, you'll quickly discover that it doesn't work. At all. Until you completely disable error reporting, that is. And even then, chances are it still won't work because the documentation doesn't provide instructions on how to use it correctly and the one example (which is mentioned nowhere, and can only be found by manually poking through the directory structure of the downloaded SDK) doesn't even work.
I use PayPal's standard payment system to accept Jetpants subscription payments and it works fine, but for godssake, do yourself a favor and stay away from their so-called "professional" API. There's nothing professional about it.
WordPress's idea of SQL injection security: addslashes
In the spirit of improving the quality of open source software, I’ve decided to launch a whole new category here on wonko.com. I’m calling it Crappy Code. Whenever I come across a really crappy piece of code in an open source application, I’ll write a cantankerous, insult-laden post all about how crappy it is and then, when applicable, I’ll offer up a suggestion for improving said code.
For our first installment in this series, we’ll turn to WordPress. If I had to list all the things I hate about WordPress, I’d probably kill myself instead. But here’s an example of the sorts of things that might be on that list if my suicide attempt were to fail:
- They have a stupid motto. “Code is poetry”. Blah blah. I’d be less annoyed by this if their code was actually good, but the fact that it sucks just annoys me even more.
- WordPress is one of those applications that uses 100 lines of code to accomplish a task that could have been accomplished in 10 lines if the developers had bothered to put some fucking thought into it.
- Nobody who uses WordPress actually gives a shit about how crappy the code is, so it’s insanely popular. Wound: check. Salt: check.
So now that we’ve established that I’m insanely biased, let’s get to the part where I make fun of some code. It was pretty tough finding just one thing to make fun of. I have a feeling WordPress is going to show up quite a lot in future Crappy Code posts. But to get things started I wanted something short, sweet, and simple. Lo and behold, I found it.
WordPress 1.5.2; wp-includes/wp-db.php; line 76:
// ====================================================================
// Format a string correctly for safe insert under all PHP conditions
function escape($str) {
return addslashes($str);
}
Oh dear God.
The comment is what really gets me. What genius came to the conclusion that addslashes would make all possible strings safe for use in SQL queries under all possible conditions? The addslashes function just puts a backslash (\) in front of single-quotes (‘), double-quotes (“) and NUL characters. And depending on the value of PHP’s magic_quotes_sybase setting, it might escape single-quotes with another single-quote rather than a backslash. What it doesn’t do is escape newlines, carriage-returns, or the control character \x1a, all of which need to be escaped when sending string values to MySQL.
Instead of addslashes, they should be using mysql_real_escape_string, which actually does escape every unsafe character “for safe insert under all PHP conditions”. Their code should look like this:
function escape($str) {
return mysql_real_escape_string($str, $this->dbh);
}
WordPress is one of the most widely used PHP applications in the world. They have a history of SQL injection vulnerabilities. You’d think they’d know by now which function to use for escaping strings being sent to MySQL.
Update: A helpful reader has pointed out that the issue was fixed way back in July and the fix will be in the 1.6 release.
Copyright © 2002-2013 Ryan Grove.
All rights reserved.
Colored pencil sketch by Felicity Shoulders.
Header background by Subtle Patterns / CC BY-SA 3.0