If you end up in a situation where your PHP installation gets ahead of your application (like fx. if your hosting provider deprecates PHP 7.4 without you having had the opportunity to update your WordPress 4.9.22 blog), here is a small tip if this results in errors related to the, in PHP 8 removed, function get_magic_quotes_gpc() (see PHP RFC from 2018 about this decision).
As this function has been a dummy function returning false since PHP 5.4 (see php-src commit removing the functionality) and emitting a deprecation warning since PHP 7.4 (see php-src commit deprecating function) in almost any case perceivable you would be able to fake this function and satisfy your application’s need for it to exist.
To fix this for WordPress add the following line to the wp-includes/load.php file (fx. at line 7 for v4.9.22);
function get_magic_quotes_gpc() {return false;}
And voila! WordPress will be functional again (please consider using the chance to upgrade).
Unless, of course, there are other problems related to the PHP upgrade…
This could fx. be ancient themes (like Ahimsa) that use deprecated associative array notation (unquoted string literal indexes). These needs fixing first by adding quotes to all of the indexing strings in sub-arrays of the $skin_fields array, like below;
$skin_fields = array ( array ( "name" => "skinpagebgtopbg", "desc" => "Page Background Top", "csssel" => "#bgtop", "attr" => "background-color" ), array ( "name" => "skinpagediv", "desc" => "Page Background Divider Colour", "csssel" => "#bgtop", "attr" => "border-bottom-color" ), array ( "name" => "skinpagebgbotbg", "desc" => "Page Background Bottom", "csssel" => "BODY", "attr" => "background-color" ), array ( "name" => "skinhyperlinks", "desc" => "Hyperlinks", "csssel" => "A", "attr" => "color" ), array ( "name" => "skincapsulebg", "desc" => "Default Bubble Background", "csssel" => ".capsule", "attr" => "background-color" ), array ( "name" => "skincapsulefg", "desc" => "Default Bubble Text Colour", "csssel" => ".capsule", "attr" => "color" ), array ( "name" => "skinheaderbg", "desc" => "Header Background", "csssel" => "#header", "attr" => "background-color" ), array ( "name" => "skinheaderfg", "desc" => "Header Text Colour", "csssel" => "#header, #header table, #header a", "attr" => "color" ), array ( "name" => "skinheadersepcolour", "desc" => "Colour of Separator Bar in Header", "csssel" => "#title", "attr" => "border-right-color" ), array ( "name" => "skinsidebarbg", "desc" => "Sidebar Background", "csssel" => ".sidebar, .tdsidebar", "attr" => "background-color" ), array ( "name" => "skinsbwidgetbg", "desc" => "Sidebar Widgets Background", "csssel" => ".sidebarlist", "attr" => "background-color" ), array ( "name" => "skinsbwidgetfg", "desc" => "Sidebar Widgets Text Colour", "csssel" => ".sidebarlist", "attr" => "color" ), array ( "name" => "skinsblegendbg", "desc" => "Sidebar Widget Title Background", "csssel" => ".sidebarlist > legend", "attr" => "background-color" ), array ( "name" => "skinsblegendfg", "desc" => "Sidebar Widget Title Text Colour", "csssel" => ".sidebarlist > legend", "attr" => "color" ), array ( "name" => "skinsblistdiv", "desc" => "Sidebar/Action Lists Divider Colour", "csssel" => ".sidebarlist li, #postaction li", "attr" => "border-top-color" ), array ( "name" => "skinsblink", "desc" => "Sidebar Widget Hyperlinks", "csssel" => ".sidebarlist a", "attr" => "color" ), array ( "name" => "skincalcaption", "desc" => "Sidebar Calendar Caption Colour", "csssel" => "#wp-calendar caption", "attr" => "color" ), array ( "name" => "skincalheaderbg", "desc" => "Sidebar Calendar Column Header Background", "csssel" => "#wp-calendar thead th, #wp-calendar tfoot td.pad", "attr" => "background-color" ), array ( "name" => "skincalheaderfg", "desc" => "Sidebar Calendar Column Header Text Colour", "csssel" => "#wp-calendar thead th", "attr" => "color" ), array ( "name" => "skincalcellfg", "desc" => "Sidebar Calendar Entries Text Colour", "csssel" => "#wp-calendar tbody td", "attr" => "color" ), array ( "name" => "skincalnpbg", "desc" => "Sidebar Calendar Next/Prev Links Background", "csssel" => "#wp-calendar #next, #wp-calendar #prev", "attr" => "background-color" ), array ( "name" => "skincalnpfg", "desc" => "Sidebar Calendar Next/Prev Links Text Colour", "csssel" => "#wp-calendar #next, #wp-calendar #prev, #wp-calendar tfoot a", "attr" => "color" ), array ( "name" => "skintextwdgtfg", "desc" => "Sidebar Text Widget Text Colour", "csssel" => ".textwidget", "attr" => "color" ), array ( "name" => "skincontentbg", "desc" => "Main Content Background", "csssel" => "#content", "attr" => "background-color" ), array ( "name" => "skinpostpagebg", "desc" => "Post or Page Entry Background", "csssel" => ".post > fieldset", "attr" => "background-color" ), array ( "name" => "skinpostpagefg", "desc" => "Post or Page Entry Text Colour", "csssel" => ".entry", "attr" => "color" ), array ( "name" => "skinpptitlebg", "desc" => "Post, Page, Comments Title Background", "csssel" => ".post .title, #comments > legend, .comment > legend, #responsebox > legend", "attr" => "background-color" ), array ( "name" => "skinpptitlefg", "desc" => "Post, Page, Comments Title Text Colour", "csssel" => ".post .title, .post .title a, " . "#comments > legend, .comment > legend, #responsebox > legend", "attr" => "color" ), array ( "name" => "skinmetabarbg", "desc" => "Post/Page/Comment Bottom Bar Background", "csssel" => ".postmetadata", "attr" => "background-color" ), array ( "name" => "skincattagbg", "desc" => "Category/Tag Lists Background", "csssel" => ".postcattags", "attr" => "background-color" ), array ( "name" => "skincattagfg", "desc" => "Category/Tag Lists Text/Link Colour", "csssel" => ".postcattags, .postcattags a", "attr" => "color" ), array ( "name" => "skin1cattagbubblebg", "desc" => "Single Post Cat/Tag Bubble Background", "csssel" => "#single .postcattags .capsule", "attr" => "background-color" ), array ( "name" => "skin1cattagbubblefg", "desc" => "Single Post Cat/Tag Bubble Text/Link Colour", "csssel" => "#single .postcattags .capsule, #single .postcattags .capsule a", "attr" => "color" ), array ( "name" => "skinbqbg", "desc" => "Blockquote Background", "csssel" => "blockquote", "attr" => "background-color" ), array ( "name" => "skinbqfg", "desc" => "Blockquote Text Colour", "csssel" => "blockquote", "attr" => "color" ), array ( "name" => "skinlistbg", "desc" => "Page/Post Ordered/Unordered List Background", "csssel" => ".entry UL, .entry OL", "attr" => "background-color" ), array ( "name" => "skinlistfg", "desc" => "Page/Post Ordered/Unordered Text Colour", "csssel" => ".entry UL, .entry OL", "attr" => "color" ), array ( "name" => "skinpost1stletterfg", "desc" => "Post First Letter Colour", "csssel" => ".entry > P:first-child:first-letter", "attr" => "color" ), array ( "name" => "skinactionbg", "desc" => "Action Bubbles (Edit, Reply, etc) Background", "csssel" => ".actbubble", "attr" => "background-color" ), array ( "name" => "skinactionfg", "desc" => "Action Bubbles (Edit, Reply, etc) Text Colour", "csssel" => ".actbubble, .actbubble a", "attr" => "color" ), array ( "name" => "skincommentsbg", "desc" => "Comments Block Background", "csssel" => "#comments", "attr" => "background-color" ), array ( "name" => "skincommentbg", "desc" => "Comment Background", "csssel" => "fieldset.comment, fieldset.comment .commenttext", "attr" => "background-color" ), array ( "name" => "skincommentfg", "desc" => "Comment Text Colour", "csssel" => "fieldset.comment .commenttext", "attr" => "color" ), array ( "name" => "skinresponsebg", "desc" => "Response Box Background", "csssel" => "#responsebox", "attr" => "background-color" ) );
Tænk hvor meget trafik, processerings- og ventetid der ville være sparet hvis nogen gad at overveje hvad billeder på en hjemmeside anvendes til og tilpasse de transmitterede data derefter!
Her et enkelt sølle eksempel af mange observerede (ingen særlig grund til at klandre den specifikke afsender her, blev bare trigget af at klikke på et link i et nyhedsbrev just modtaget) fra SDFE‘s nyhedsoversigtsside, hvor det er så åbenlyst tydeligt på billedindlæsningshastigheden at billederne er alt for meget større end nødvendigt.
Inspicering i browseren (f.eks. med Firefox dev-tools: F12->Network) viser da også at billedindholdet fylder 14,85 MiB ud af sidens samlede størrelse på 16,23 MiB (91,5%).
SDFE.dk nyhedsoversigtsside, billederoverførsel
Hvad værre er at billederne på denne side kun anvendes som meget små illustrationer til en række artikler, men hentes som enorme filer i opløsningen 1920×1080. Inspektion af det første billede i browserens DOM-inspektør (Firefox: F12->Inspector) afslører at browseren kun viser billedet i en opløsning på 100×56! Der går altså 1920*1080-100*56=2’068’000 (99,73%) pixels til fuldstændig spilde.
SDFE.dk digebillede, vist størrelse vs. datastørrelse
Et hurtigt forsøg med at nedskalere et enkelt billede (terminal-foo!), uden at gå ind i så avancerede emner som JPG-kompressionskvalitet eller alternative billedformater (for ikke at tale om reel billedoptimering), kan give en ide om hvor meget data der egentlig overføres unødigt ved visning af denne side:
$ wget –quiet https://sdfe.dk/media/2919562/dige-1920×1080.jpg $ gm convert -resize 100×56 dige-1920×1080.jpg dige-100×56.jpg $ ls -l dige-* -rw-rw-r– 1 miki miki 17420 Apr 30 15:54 dige-100×56.jpg -rw-rw-r– 1 miki miki 1568308 Apr 24 14:54 dige-1920×1080.jpg $
Billedets størrelse reduceres her fra 1’568’308 bytes (1,60 MiB) til 17’420 bytes (17,01 KiB). Det er relativt en besparelse i overførselsmængden på dette billede på 8903%, vel at mærke med nøjagtigt det samme visuelle udbytte! For ikke at tale om den besparelse i hukommelsesforbrug og processeringstid der også opås ved at sidebeskuerens browser skal forholde sig til en tilsvarende mindre mængde data.
Under antagelse af at tilsvarende reduktioner kan opnås på det samlede sæt af billeder på denne side, vil overførselsbehovet kunne reduceres fra 15’206,40 KiB til 170,80 KiB. Tænk lige over det næste gang, webmaster!
Hit an odd browser behaviour today.
Trawling through some of those nice and dandy terms for a service (no I won’t tell) I followed a link and suddenly hit an “insecure connection” message from Firefox.
Examining the certificate using the usual “openssl s_client” and “openssl x509” tools surely enough revealed that the served certificate didn’t include the second-level but only on the third-level www sub-domain. Strangely enough I discovered that when entering the same URL directly into the address bar of Firefox the connection was somehow redirected to the www sub-domain and loaded fine without any complaints from Firefox.
Looking into what was happening on the wire using wget directed to not check the certificate (–no-check-certificate) and displaying server responses (–server-response/-S) revealed that the server behind the misconfigured certificate was aiming to issue a HTTP 301 redirect to the valid www sub-domain of the site (actual site replaced by foo.bar and localhost ip);
$ wget –server-response –no-check-certificate –output-document=/dev/null https://foo.bar –2018-11-15 18:59:14– https://foo.bar/ Resolving foo.bar (foo.bar)… 127.0.0.1 Connecting to foo.bar (foo.bar)|127.0.0.1|:443… connected. WARNING: no certificate subject alternative name matches requested host name ‘foo.bar’. HTTP request sent, awaiting response… HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: https://www.foo.bar/ Date: Thu, 15 Nov 2018 17:59:13 GMT Content-Length: 152 Location: https://www.foo.bar/ [following] …
Apparently Firefox’s behaviour in this scenario differs depending on the method in which the user is supplying the URL, in some cases silently ignoring the TLS/SSL warning. A little more experimentation revealed that it was actually not the source of the URL, link followed versus one entered in address bar, that made any difference. Instead it is the presence of a trailing slash on the URL that triggers the silent suppression of the serious red flag that the second-level domain asked to be fetched is not present in the served certificate. I was fooled by the fact that when entering URLs in the address bar Firefox suggests ending the URL on a slash (‘/’) if it is not already present. Manually removing this when editing in the address bar also makes Firefox display the security warning. Alas, the link I originally followed was also missing the trailing slash and behaved as expected by throwing me into a security warning.
The whole “feature” of silently ignoring a security issue seemed very odd to me, but a bit of searching revealed that this was apparently championed by Google Chrome a couple of years ago. It is described in this servertastic post which also directs to a discussion on Twitter, with some key points replicated below, about its presence in Chrome and confirmation from a Chrome team member that the behaviour is intended.
Interesting. Chrome recognizes https ://onlineservices.nsdl.com has a cert valid only for www and redirects to https://www… @Scott_Helme pic.twitter.com/j9XdqiXqAI — Anand Bhat (@_anandbhat) October 26, 2016
Interesting. Chrome recognizes https ://onlineservices.nsdl.com has a cert valid only for www and redirects to https://www… @Scott_Helme pic.twitter.com/j9XdqiXqAI
— Anand Bhat (@_anandbhat) October 26, 2016
invalid cert for raw TLD but valid cert for www will trigger redirection down to www — Adrienne Porter Felt (@__apf__) October 26, 2016
invalid cert for raw TLD but valid cert for www will trigger redirection down to www
— Adrienne Porter Felt (@__apf__) October 26, 2016
The thread ends with a guy who had dug up the source code of the feature in Chromium (on which Chrome is based) known as “SSLCommonNameMismatchHandling” in file browser/ssl/common_name_mismatch_handler.cc (see all mentions across code base).
This has obviously also trickled down into Firefox, however, not much mention of that is to be found. Not even traces of it by some quick searches of the mozilla-central codebase. Some day I promise (really!) to dig through all source of Mozilla and hunt down the implementation, but for now I’ll revert to a bit of practical experimentation showing the behaviour in the different browsers and operating systems I happen to have access to at the moment;
So somewhere between 59.0.3 and 62.0.2 Firefox also implemented a policy of silently accepting invalid certificates when certain non-obvious criteria is met (is the redirect actually followed and certs checked, or is “www.” just prefixed?), but this happens only when the URL ends on a slash. Go figure…