Category Archives: Internet

All blogposts on blog.futtta.be about Internet (browsers, web development and mobile web).

WP SEO vs Autoptimize; who broke your WordPress?

Autoptimize 1.9 was released yesterday but unfortunately some reports were coming in about JS optimization being broken.  At first I suspected the problem being related to small changes that added semi-colons to individual blocks of script (before being aggregated), but tests with some impacted users showed this was not the case.

The breakthrough came in this thread in Autoptimize’s support forum, where user “grief-of-these-days” confirmed the problem started with the update of WP SEO and specifically the “sitelinks search box“-functionality that was added in WP SEO 1.6. Sitelinks Search Box comes as an inline script of type “application/ld+json”, that contains a name-less JSON-object with “linked data”. Autoptimize detected, aggregated and minimized this name-less object, but that not only defies the sitelinks search box mechanism, but potentially also broke the optimized JS itself. So I updated & enabled WP SEO, confirmed the problem, identified “potentialAction” as unique string to base exclusion on and pushed out 1.9.1 which will now no longer Autoptimize Sitelinks Search Box-code.

So who broke your WordPress today, WP SEO or Autoptmize? Well, WP SEO’s update may have made the bug appear, but based on the fact that json-ld is standardized and as such will probably be also present in other guises, Autoptimize should really just exclude any script of the “application/ld+json”-type from being aggregated & minimized (and not just that of the Sitelinks Search Box). Adding to the to-do-list now!

(When) should you Try/Catch Javascript?

Autoptimize comes with a “Add try-catch wrapping?”-option, which wraps every aggregated script in a try-catch-block, to avoid an error in one script to block the others.

I considered enabling this option by default, as it would prevent JS optimization occasionally breaking sites badly. I discussed this with a number of smart people and searched the web, eventually stumbling on this blogpost which offers an alternative for try-catch because;

Some JavaScript engines, such as V8 (Chrome) do not optimize functions that make use of a try/catch block as the optimizing compiler will skip it when encountered. No matter what context you use a try/catch block in, there will always be an inherent performance hit, quite possibly a substantial one. [Testcases] confirm [that] not only is there up to a 90% loss in performance when no error even occurs, but the declination is significantly greater when an error is raised and control enters the catch block.

So given this damning evidence of severe performance degradation, “try/catch wrapping” will not be enabled by default and although Ryan’s alternative approach has its merits, I’m weary of the caveats so I won’t include that (for now anyway). If your site breaks when enabling JS optimization in Autoptimize, you can enable try/catch wrapping as a quick workaround, but finding the offending script and excluding it from being optimized is clearly the better solution.

Next Autoptimize eliminates render-blocking CSS in above-the-fold content

Although current versions of Autoptimize can already tackle Google PageSpeed Insights’ “Eliminate render-blocking CSS in above-the-fold content” tip, the next release will allow you to do so in an even better way. As from version 1.9 you’ll be able to combine the best of both “inline CSS” and “defer CSS” worlds. “Defer” effectively becomes “Inline and defer“, allowing you to specify the “above the fold CSS” which is then inlined in the head of your HTML, while your normal autoptimized CSS is deferred until the page has finished loading.

Other improvements in the upcoming Autoptimize 1.9.0 include:

  • Inlined Base64-encoded background Images will now be cached as well and the threshold for inlining these images has been bumped up to 4096 bytes (from 2560).
  • Separate cache-directories for CSS and JS in /wp-content/cache/autoptimize, which should result in faster cache pruning (and in some cases possibly faster serving of individual aggregated files).
  • CSS is now added before the <title>-tag, JS before </body> (and after </title> when forced in head). This can be overridden in the API.
  • Some usability Improvements of the administration-page
  • Multiple hooks added to the API a.o. filters to not aggregate inline CSS or JS and filters to aggregate but not minify CSS or JS.
  • Multiple bugfixes & improvements

On the todo-list; testing, some translation updates (I’ll contact you translators in the coming week) and updating the readme.txt.

The first test-version of what will become 1.9.0 (still tagged 1.8.5 for now though) has been committed to wordpress.org’s plugin SVN and can be downloaded here. Anyone wanting to help out testing this new release, go and grab your copy and provide me with feedback.

My Adventures on OpenShift

openshiftI have always been a fan of Red Hat, even if have never used their products extensively. They were one of the original movers in Linux-market back when Slackware was big and when InfoMagic CD-rom boxes with multiple distro’s were popular. And I have remained a fan because they succeeded in building a solid company built on and around open source & services.

So I was very happy to read that Red Hat had entered the PAAS-market with OpenShift, that that platform was built on open source(d) solutions and that a small-timer like me could deploy apps for free on their application cloud. I signed up, installed the WordPress instant application, added some tried & tested plugins and imported my content. Half an hour works, tops and performance proved to be great. Everything was just peachy, until I received this message in my mailbox;

We believe your use of OpenShift violates the Services Agreement and Acceptable Use Policy both of which can be found here: https://openshift.redhat.com/app/legal/

Infected file(s):
/var/lib/openshift53bcc3fd5973cabac00000d1/.tmp/53bcc3fd5973cabac00000d1/just_test_bc: Perl.Shellbot-8

And ZAP, my application was removed. As I had no idea how “just_test_bc” ended up in a temp-folder, the only possibility was a successful hack-attempt, so I contacted the security team to get more information. It took some time (and an escalation via the Customer Enablement Team), but I eventually got in touch with Stefanie at Red Hat, who was able to provide me with more information:

It looks like we had a one-off error in the script that emailed you. Your application was still flagged, but on a different file than we emailed about. This is the actual file:

/var/lib/openshift/53bd21435973cad637000080/mysql/data/ib_logfile0: PHP.ShellExec

So there was something in the mysql database log that set off the scan. [...] It looks like mysql may have logged someone’s attempt to inject some bad PHP code into your app.

ib_logfiles are MySQL’s innodb replay log files and as Stefanie provided me with a tarball with my entire application, I extracted ib_logfile0 and used “strings” to extract readable information from the binary file. The result (from my mail to Stefanie);

Although php’s exec (and similar functions) can be found [in the logfile], this is always due to … blogposts about web security and specifically this one; http://blog.futtta.be/2007/12/02/php-security-eval-is-evil/. The content of that article was inserted in the DB and [thus] added to ib_logfile. Your scanner finds the content [in that innodb replay logfile] and flags this as a problem. I would think the OpenShift scanner needs some finetuning, [as now] anyone is at risk of having their app auto-removed if the mysql-redo-logfile happens to contain vaguely “offending” strings such as shell_exec?

OpenShift confirmed this analysis;

You’re absolutely right that our scanner needs work. So what I’m going to do is get you onto a whitelist so this thing doesn’t flag you again. [...] All takedowns are currently on hold until I can implement pre-removal notifications [and] improve our standard operating procedure for this kind of thing. That should give people a chance to tell us that their apps are not malicious, so that we can whitelist others too, if needed. As long as they notice an email saying “OpenShift Terms Of Service Violation” within a few days, I think they should be safe. If they do get flagged as a false positive like your app did, they’ll email us back and let us know it’s a mistake, and then they’ll be added to the whitelist too.

Now wasn’t that an interesting adventure? If ever you get a notification-mail from OpenShift related to security issues, check if the problem isn’t with benign content being inserted in the database and if so be sure to contact OpenShift so they can add you to their whitelist.

WP DoNotTrack whitelist & WordPress/ Jetpack stats

Although the number of pageviews of this blog already decreased from approx. 2100 pageviews per week before mid May to 1300 pv/week after (I never thought I’d ever be hit by a Panda), yesterday was an absolute disaster. Turns out that Automattic changed the domain of the Jetpack stats tracking pixel to pixel.wordpress.com, which WP DoNoTrack (for which I pushed out a small update in May) blocked as that domain was not whitelisted. The downside of white- instead of blacklisting.

WordPress-as-a-service tip: Flywheel

flywheelAt work I was asked to provide advice on WordPress hosting. As we don’t have in-house LAMP-experience and as I didn’t want to have to take care of server operations myself (been there, done that), I decided to look into WordPress as a service solutions. To make things a tad more complicated, hosting had to be in a European data-center as we wanted optimal performance for our local customers and as our Privacy Officer requires all company data to be in Europe.

I contacted several US companies, but eventually Flywheel came out on top; they confirmed they could host in Europe (Amsterdam), seemed pretty eager, had a great package and they could provide me with a test-account to play around with their solution. And so I did; I set up a stock WordPress 3.9.x with Autoptimize and WP YouTube Lyte (call me prejudiced, but I like my own plugins), imported a bunch of posts from this blog and had WebPageTest be the judge.

The results were quite impressive;

Document CompleteFully Loaded
Load timeFirst byteStart renderDOM elemsTimeReqsBytes InTimeReqsBytes In
First View (Run 3)0.457s0.120s0.292s9260.457s473 KB1.008s12152 KB

0.120s until first byte, 0.292s start render and 0.457s doc complete? Sweet! So yeah, given those numbers, their offering and the fact they can deploy to a datacenter in Europe I do think Flywheel is a great choice for those who are looking for WordPress-as-a-service (well, PAAS really) solution!

Android Chrome bug when styling unicode character?

symbols CSS weirdness in chrome for androidWhile experimenting with the use of Unicode characters in a small proof of concept, I stumbled upon what I think is a bug in Chrome for Android. Apparently character &#9776;, which renders as ☰ and which most people consider the “options”-icon, cannot be given a color in Chrome for Android whereas other Unicode characters can.

As you can see when visiting this test-page, the 3 symbols styled correctly (font color white) in most browsers (tested on IE8, FF on W7, Ubuntu and Android, Chrome on W7 and Ubuntu), but the options-symbol is not white on Chrome for Android (at least on my Samsung Galaxy S4).

So, does this qualify as a bug, or did I just mess up? Anyone happens to know a workaround?