Category Archives: Internet

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

WP YouTube Lyte now parses normal YouTube links as well

I was just being a jealous guy, seeing how normal YouTube embeds (oEmbeds) got previewed nicely in WordPress 4.0 TinyMCE editor. This had been on my wishlist for a long time already and I looked into enabling that for httpv-links and lyte-shortcodes as well, but that turned out not to be that simple.

So I took the alternative approach, enabling WP YouTube Lyte to act on normal YouTube-links (a much requested feature anyhow) and thereby piggy-backing on the TinyMCE-improvement in 4.0. So there you have it; lyte video’s can be inserted using normal YouTube links and that will result in a (non-lyte) preview of the video in the visual editor content box.

1.5 as a number of other improvements and bugfixes, but you can read all about those in the changelog.

Have fun with this small Rick James like party-track to celebrate 1.5.0 (and my birthday, while we’re at it);

Mark Ronson – Uptown Funk ft. Bruno Mars

Watch this video on YouTube or on Easy Youtube.

Verder sleutelen aan mijn m.deredactie.be-alternatief

futtta-redactie-tabs-compressorDat ze daar aan de Reyerslaan niet stilzitten; http://m.deredactie.be/ is nu ook bruikbaar op een JavaScript-loze browser! Dat klinkt misschien onbelangrijk, maar zo een basis-versie die werkt, ongeacht de browser, is een grote stap in wat ik de juiste richting acht. Spijtig genoeg blijft de site voor de rest onder Google’s verwachtingen en de laadtijd en total download size blijven een mobiele site onwaardig. Daar ten gronde iets aan veranderen binnen het kader van de gekozen architectuur (MVC in de browser) zal niet eenvoudig zijn.

Daarom ben ik dus ook niet blijven stilzitten en sleutelde ik verder aan mijn alternatief voor m.deredactie.be. Video werkt nog steeds niet (misschien moet ik eens kijken of ik iets kan doen met de JS-file van de VRT), maar onder andere deze verbeteringen zijn er wel bij:

  • Op de homepage hebben “hoofdpunten”en “laatste nieuws” nu elk een eigen tab (ik ben zelf niet overtuigd van de kleurenkeuze, maar soit).
  • Op de detail-pagina’s kun je artikels delen op sociale media (met lyteshare.js)
  • De html is opgekuist en valideert nu bijna op de W3 validator (bijna maar nog niet helemaal; de imgsrc attributen op placeholder-divs voor image lazyloading mogen niet).

Daarnaast zitten er nog een handvol bugfixes en andere kleine wijzigingen in, cfr de  “done” lijst op Trello. Pagespeed Insights score en webpagetest.org testresultaten zijn nog steeds “up to snuff”. De geüpdate code staat op GitHub en het resultaat (als je het projectje niet zelf wilt/ durft/ kunt installeren) zie je op http://futtta.be/redactie/.

I see you baby, purging that spam!

all we are saying, is give ham a chance!While Akismet does a good job at flagging comments as spam, it by default only purges spam (from the comments and comments_meta tables) after 15 days.

So it’s a good thing Akismet now has a filter to change the amount of days after which spam is removed. Below code (in a small plugin or in a child theme’s functions.php) should do the trick.

/** tell akismet to purge spam sooner */
add_filter('akismet_delete_commentmeta_interval','change_akismet_interval');
add_filter('akismet_delete_comment_interval','change_akismet_interval');

function change_akismet_interval($in) {
     return 5;
}

Happy purging!

Tweaking WordPress’s Expound theme’s 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 > .menu-item {
        border-bottom: 6px solid #3A3A3A !important;
  }
  .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 m.deredactie.be

Dat ik niet content was met de vernieuwde mobiele redactie.be 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 deredactie.be (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 m.deredactie.be 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 m.deredactie.be, 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!