Earlier this year, I followed-suit with my usual routine of social media sabbaticals (which is just a fancier way of saying “time off of social media” 🎩).
If you’re new to reading this site, you can read my past entries here:
- The First Social Media Sabbatical of 2018
- The Second Social Media Sabbatical of 2018
- The Third Social Media Sabbatical of 2018
- Time Off 2019: Part 1 of 4 of Social Media Sabbaticals
This is something I’ve been doing for a while now, and it’s something that I’ve found useful both for my personal and professional life.
And I don’t want to try to come up with some other reason for doing this so I’ll quote my previous post (because quoting yourself isn’t narcissistic or anything, is it?):
Every time I end up taking time off of social media in general, I never regret it. At the same time, I also find new things I want to do during that time.
But one of the things I like do during this post other than share that I am doing it (because I see this site as the primary place to keep up with me – not Twitter, not Instagram, not AIM, not ICQ), I like also to cover what I plan to do.
So here’s what I’m looking to do during August.
Continue reading “Time Off 2019: Part 2 of 4 of Social Media Sabbaticals Taking time off of social media is something I’ve done for a while now, and it’s something that I’ve found useful both for my personal and professional life.“
It’s one thing to be using PHP CodeSniffer manually but if you’re using a utility such as GrumPHP to check your work before committing it to the repository, then you’re likely going to want to use the version that you’re installing with your project.
This assumes that:
- You are installing PHP CodeSniffer local to your project,
- You want to install a specific set of coding standards to run against your code.
Remember, this is also done in the context of wanting to run automated scripts during the commit process and in a local environment (versus a global setting) with Composer.
Continue reading “Adding Multiple Coding Standards with Composer To install multiple coding standards with Composer, we need to take advantage of the pre-install-cmd and the pre-update-cmd scripts.“
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.
Continue reading “How To Remove Images with DOMDocument The purpose is to show how to replace the src attribute if the URL doesn’t properly resolve. Thus, how to remove images with DOMDocument.“
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).
Continue reading “The Difference in cURL and WordPress Requests cURL and WordPress remote requests allow us much of the same functionality. But we need to be able to determine which option is best.“
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.
Continue reading “When The Browser and Terminal Show Different Versions of PHP If you’re seeing the browser and the terminal show different versions of PHP then something is wrong. “