Category Archives: Internet

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

Tweaking WordPress’s Expound theme menu

I’m helping on a site for a not-for-profit for which we selected “Expound” as the base theme. I like Expound; it looks great, there’s no jQuery- or webfont-cruft to worry about and although the CSS comes with a seperate reset.css-file, it does (Auto-)optimize perfectly.

But I wasn’t happy with the menu color-scheme and with the fact that the menu lacked an indication that a child page of a main entry was being shown instead of the page of that main entry itself (confused much?).

Anyway, this is what I ended up with;
wordpress expound theme menu tweaked

For those wanting to do something similar, this is the relevant CSS in my child theme;

/* don't want no blue */
.navigation-main .current-menu-item > a {
        background: #557B47 !important;

/* triangle should not be blue either, need it to be a bit bigger */
.navigation-main ul > .current_page_item a:after, .navigation-main ul > .current-menu-item a:after, .navigation-main ul > .current-post-ancestor a:after, .navigation-main ul > .current-menu-parent a:after, .navigation-main ul > .current-post-parent a:after {
        border-top: 10px solid #557B47 !important;
        bottom: -14px;
        z-index: 1000;

@media screen and (min-width: 600px) {
  /* if page from submenu, add line under parent item to show your in that submenu */
  .navigation-main ul > .current_page_item, .navigation-main ul > .current-menu-item, .navigation-main ul > .current-post-ancestor, .navigation-main ul > .current-menu-parent, .navigation-main ul > .current-post-parent {
        border-bottom: 6px solid #557B47 !important;

  /* but not in submenu */
  .navigation-main .sub-menu > .menu-item {
        border-bottom: 0px !important;

  /* less padding at the bottom to compensate for that extra line */
  .navigation-main a {
        padding: 10px 10px 4px !important;

  /* except when in submenu */
  .navigation-main .sub-menu a {
        padding: 10px !important;;

/* change color to default brown if child-item is active */
.navigation-main ul > .current_page_item, .navigation-main ul > .current-menu-item, .navigation-main ul > .current-post-ancestor, .navigation-main ul > .current-menu-ancestor, .navigation-main ul > .current-menu-parent, .navigation-main ul > .current-post-parent {
        background: #3A3A3A !important;

Have fun!

Mijn alternatief voor

Dat ik niet content was met de vernieuwde mobiele schreef ik hier al. Maar commentaar spuien kan iedere blogger, afbreken is makkelijker dan opbouwen en het beste argument is een uitgewerkt alternatief. Vandaar; ik werkte de afgelopen maanden tussen de soep en de patatten aan een eigen “progressive enhanced” Proof of Concept van een mobiele (in PHP) die op alle browsers werkt, minder mobiele data verbruikt en sneller rendert (hier moet ge zijn, ongeduldigaard).

Waarom ik denk dat deze aanzet beter is dan de officiële versie van de VRT? Wel, de POC

  • futttas-redactie-pagespeed-insightsis op elke browser te bekijken, ook als er geen (of slechte) JavaScript-ondersteuning is. Opera Mini? Lynx? De Netfront op uw grootvader’s Nokia? Geen probleem!
  • kan makkelijk uitgebreid worden om afhankelijk van context de presentatie anders toe doen, bv. op tablet de nieuwscategorieën permanent aan de linkerkant
  • de download-size is véél kleiner (en vreet dus minder van uw mobile data-abonnement); 472KB (document complete) en 979KB (fully downloaded) vs 126 en 127KB
  • de site rendert véél sneller (en spaart uw batterij dan ook meer); 7.419s vs 1.557s
  • Google PageSpeed Insight geeft een mobile score van 61/100 tegenover 97/100 voor deze POC (91/100 indien de data niet uit de cache, maar van VRT komt)

Je kunt:

Een paar technische feitjes;

  • De basis-versie werkt volledig zonder JavaScript. Als JS aanwezig is en “up to snuff” (cfr. cut the mustard), wordt de ervaring “verrijkt” (fixed header, uitklapbare navigatie, lazy-loading van images …).
  • Alle CSS en JS staat -weliswaar slordig maar oh zo performant- inline (behalve aniHead.js, een onafgewerkte en dus inactieve “verrijkings”-PoC in de PoC, type aniHead(); in de console om te activeren).
  • De POC gebruikt dezelfde data-feeds als, maar haalt die server-side binnen (dependancy; Curl)
  • Data wordt -gecomprimeerd- gecachet in APC cache (dependancy; APC)
  • Externe HTML in de data-feeds (iframe, script of object van bv. Twitter & Facebook) wordt rudimentair weggefilterd, maar dat is een optie in de code ($trustHTML=false;)
  • De code-kwaliteit is ongetwijfeld beneden alle peil (geen OO, geen MVC, veel spaghetti), maar ik ben dan ook geen èchte developer.
  • Grootste missing feature is video (er zijn er nog, zie Trello-board)

Zo, dat is het zo wat. Bekijk het eens, geef commentaar, fork op GitHub, fix bugs, voeg features toe. Maar wat je ook doet, vergeet niet dat de content van VRT is en blijft en dat je daar dus niet zomaar wat mee kunt doen.

Amazed by Autoptimize take-up

autoptimize at +200K downloads, wow!Less then a year after reaching 100000 downloads, Autoptimize broke the 200000 barrier just last week.

It’s also exiting to see how people are blogging (or tweeting) about it as well;

So yeah, I’m pretty amazed by how well Autoptimize is doing. Thanks for the confidence!

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’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:

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; 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.