This post was originally made 3/7/2019 but was lost during a restoration from backup while Ultimate SEO was dealing with a DOS attack.
Updates That Matter AND Updates That Don’t
I’ve heard things come in threes so curious whats next because 2 big updates this week are out. Now unfortunately the one that matters is unlikely to gain as much attention as the one that doesn’t mean anything. So lets begin on what folks are focused on…something that means nothing.
MOZ Domain Authority 2.0
Moz redid their Domain Authoritycalculations and the implications are HUGE for those who workat Moz. If you don’t workthere then its not a big deal. Domain Authorityis like a fake credit score. Your bank will likely use your FICA score but no one can release your FICA score to you but FICA. To solve this banks and other organizations created their own scoring systems that attempted to mimic your FICA score that they can give out to you on credit monitoring sites. These numbers though aren’t really that important as they are guesses to what your FICA score should be…VantageScore for instance gives a person a score based on their credit history thats also 3 digits but it isn’t a FICA score. If you bank uses FICA scores who cares what your score is at VantageScore.
Moz made up Domain Authorityand Google doesn’t use it. So a change to calculating Domain Authorityfrom Moz does not mean a change in search engine ranking. Domain Authority is useful to you because it’s an educated guess as to what Google thinks just like Citation and Trust Flow are guesses by Majestic.
I don’t know about everyone else but the new calculations vastly changed the impression some would have of several domains I operate. Here are some examples:
Moz DA April 2019 – March 2019 – Backlinks
But again, Domain Authority has value when used among multiple other metrics geared at assessing a site’s rank ability.
PHP 7.3 Released And Available To Cpanel Servers
Its out and you can now run your site on it if you’re using Cpanel/WHM servers. Im focused on Cpanel because its highly popular …. unless you use Wix or Shopify which use propreietary server management software that isn’t an industry standard. Now, likely you don’t even use 7.2 as many sites still operate on PHP5.6. BUT here are the advantages of 7.3
Now its relevant to SEObecause WordPressruns on PHP and WordPressis an SEOfavorite. While new features are great and PHP 7 has proven much faster than PHP 6 this newest update may require some caution. PHP 7.3 Issue With WordPress 5
We have some testing done by others that note”
We wanted to test whether PHP 7.3 was performing better than PHP 7.2, and therefore bypassed the reverse proxy and ran tests directly against the backend web server running the PHP, effectively bypassing all caching. The tests were run from the server to eliminate network bias.
We used as the testing tool, running 3 000 requests with a concurrency of 1000, with keep alive enabled. ….
We did a few more compiles of PHP 7.3, and tested benchmarked those. We also did benchmarks on all major versions from 5.6 and up. See the results in the table below.
PHP and Database
|Req/s||PHP 5.6||PHP 7.0||PHP 7.1||PHP 7.2||PHP 7.3||PHP 7.3 v2||PHP 7.3 v3|
We ran this test 3 times on PHP 7.2 and three times on PHP 7.3, and compared the numbers.
PHP 7.2 average: 192 requests per second
PHP 7.3 average: 224 requests per second
The results were consistent with very small variation. WordPress with WooCommerce running PHP 7.3 outperforms PHP 7.2 by 16.67%.
So what are you waiting for? It is time to get that extra performance boost. Upgrade your site to be PHP 7.3 compatible today, and get the 10-17% extra performance boost!”
Techy Stuff In 7.3 Update
From hackernoon.com we get the features listed below:
Not having an adequate way to handle errors when using JSON has been a problem for quite a long time, and web developer all over the worlds have seen this as a huge downside of the language,
The RFC of PHP 7.3 has accepted this update by a 23 vs 0 vote which says how much this feature has been requested.
Until PHP v7.2 we needed to use a workaround to get an error from JSON and it was not reliable nor proficient in its job;
The new flag I am about to show you is an excellent alternative because give to the programmer the opportunity to use the power of exceptions that can be managed within the “try-catch” block of code.
A countable element in your code can be a variable with an array format or an object whose class is implementing the Countable interface.
Last year PHP 7.2 added a warning that shows up whenever the web developer was counting or trying to loop an uncountable element.
It is possible to solve this problem and one of the best solutions currently used is to apply a check like a snippet below:
The code checks whether the variable is an array or is an instance of the Countable interface.
And it will work but it seems a little bit “crowded” and as many of you that work long hours, after a while seeing this kind of lines wear your eyes out.
The is_countable function takes a variable as a parameter and then return a boolean depending if the function is countable or not.
There is no restriction about the format the parameter has to be, of course, if you put a non-countable variable the return will be false.
As per version 5.6 of PHP, there are over 75 built-in functions that belong to the arrays’ category.
Despite the vast numbers of tools available, at the moment, if we need to retrieve the first or the last key of an array we have to get all the keys using array_keys()and only then go for the first or last values of the array.
Another way is to opt for end()or reset().
As you may know, all the methods just described modifying the array pointer, which is something that (other than be resources consumer) you just may not want to do.
The RFC of the upcoming version proposed the introduction of 4 brand-new methods the were set to solve this issue.
The four methods were:
Among the four of them, only the one set that fetches the keys were accepted with 18 to 14 votes.
They work for both numeric and associative arrays.
The same would have worked for the other two functions illustrated in this chapter array_value_*
Just to be clear, let me repeat,
Those functions have been refused with 18 no and 15 yes.
In my opinion, these two functions would have been useful as well but according to several web developers, in certain cases, the value returned would have been ambiguous.
Here is why:
An additional option that I come across browsing on forums and talking to other web developers was to return a tuple like [$key => $value].
Even though this option will not be available on the new version, seeing the favourable responses, it might arrive with the following RFCs.
Since this is a function that did not exist before there are not going to be any backwards compatibility problems, the only issue could arrive if you have created and you are using your own version of array_key_first()and array_key_last().
Same site cookie
Deploy secure application must always be the main focus of every programmer.
One task that each of us is facing of daily basis it to diminish the risk of CSRF and information leakage attacks.
Same-site cooking declares that cookies must be sent only with request initiated from the same domain.
This is not an official standard but Google Chrome and several of the best PHP frameworks already implement it whereas Firefox and new version of other frameworks confirmed that they are planning to do so.
Currently, cookies are issued by the set-cookie header, a web developer can set a key-value pair alongside flags for the browser in order to agree if a cookie should be available or not.
This way to do things allows a vulnerable access to CSRF attacks.
The new RFC adds is suppose to solve the problem is a non-breaking mode by adding a new parameter and also modify four main functions of the language.
Two ways were proposed.
Adding a new argument to the function or allowing an array of option for moving all the options of the cookies inside.
How it will work?
Two values can be added to the same site flag present in the above functions
They are Lax and Strict.
Cookies that are using Lax will be accessible in a GET request that comes from another domain, while on the contrary Strict will not be accessible in a Get request.
Include features that Increase security in the code seem always a no-brainer but as always before deciding to apply them in our scripts we need to properly evaluate the pro and the cons of our choices
The main risk implied for using the same site flag as a supplementary argument to those functions is that it might never become an official standard.
It means that eventually browser will downturn the flag.
If this happens and you have already implemented it, it will result in you applications stuffed with junk code that need to be removed.