I’ve written about DOMDocument in a few other posts (1, 2, 3 to share a few) but I continue to find it useful in different ways.
Remember, DOMDocument is a class in PHP that allows us to manipulate the HTML document before rendering it in the browser.
From the manual:
Represents an entire HTML or XML document; serves as the root of the document tree.
Whenever I think of working with the
saveHTML function, I think of needing to serialize the new information into a file or other output stream before sending it to the browser.
But we don’t have to do that. It can be done in memory.
cURL is a very popular PHP library that I’ve referenced in several posts other posts (1 and 2, for example). And it’s one that I think should be reviewed, explored, and possibly used by anyone working in PHP (yes, even those working in WordPress).
But because of the native WordPress APIs, we do have a level of abstraction that allows us to achieve much of the same functionality (if not the same functionality).
Specifically, I’m talking about wp_safe_remote_get.
This function is ideal when the HTTP request is being made to an arbitrary URL. The URL is validated to avoid redirection and request forgery attacks.
I specifically mention the safe variant of this function for the definition above (there is another variant, but it’s important to take precautions against arbitrary URLs for security reasons).
If you happen to see two different versions of PHP whenever you run:
php -v in the console and visit
phpinfo() in the browser
Then this usually means the version of PHP that your web server is using is different than the version of PHP your command-line is using.
Specifically, this means you likely have more than one installation, and the web server is using one version, and the terminal is using a different version (in addition to using a CLI version of the interpreter).
Of course, if you’re seeing the browser and the terminal show different versions of PHP then something is wrong. You want them to be the same, but depending on how your system is configured, then you may need to update your environmental variables.
I was recently having issues with this with various installations of PHP installed via Homebrew and with my local installation of Valet.
This is what I did to fix it.
In continuing with the content of the previous post, it’s important also to consider the use of transients and authentication.
Because there are scenarios where users are authenticated on a site (think of a members-only area of a site) and or aren’t authenticated on the site (such as site visitors).
These types of situations are present both on blogs and other sites and web applications across the board.
I’ve talked about the importance of using coding standards (whatever standard you opt to use it up to you) and how to get PHP CodeSniffer (especially with Visual Studio Code) set up in several posts.
But there’s an interesting challenge that comes if you want to configure multiple coding standards with PHPCS. And this isn’t that strange a scenario, either.
Imagine you have several different projects on which you’re working – one uses WordPress’ coding standards, one uses PSR2, and one uses some other set of rules defined by the organization for which you work.
And you want to add them all as options to your configuration.