Using DOMDocument to Modify HTML with PHP
One of the first things you learn when wanting to implement a service worker on a website is that the site requires SSL (an https address). Ever since I saw the blinding speed service workers can provide a website, I've been obsessed with readying my site for SSL. Enforcing SSL with .htaccess was easy -- the hard part is updating asset links in blog content. You start out by feeling as though regular expressions will be the quick cure but anyone that has experience with regular expression knows that working with URLs is a nightmare and regex is probably the wrong decision.
The right decision is DOMDocument, a native PHP object which allows you to work with HTML in a logical, pleasant fashion. You start by loading the HTML into a DOMDocument instance and then using its predictable functions to make things happen.
// Formats post content for SSL
function format_post_content($content = '') {
$document = new DOMDocument();
// Ensure UTF-8 is respected by using 'mb_convert_encoding'
$document->loadHTML(mb_convert_encoding($content, 'HTML-ENTITIES', 'UTF-8'));
$tags = $document->getElementsByTagName('img');
foreach ($tags as $tag) {
$tag->setAttribute('src',
str_replace('http://davidwalsh.name',
'https://davidwalsh.name',
$tag->getAttribute('src')
)
);
}
return $document->saveHTML();
}
In my example above, I find all img elements and replace their protocol with https://. I will end up doing the same with iframe src, a href, and a few other rarely used tags. When my modifications are done, I call saveHTML to get the new string.
Don't fall into the trap of trying to use regular expressions with HTML -- you're in for a future of failure. DOMDocument is lightweight and will make your code infinitely more maintainable.
![5 Ways that CSS and JavaScript Interact That You May Not Know About]()
CSS and JavaScript: the lines seemingly get blurred by each browser release. They have always done a very different job but in the end they are both front-end technologies so they need do need to work closely. We have our .js files and our .css, but...
![CSS @supports]()
Feature detection via JavaScript is a client side best practice and for all the right reasons, but unfortunately that same functionality hasn't been available within CSS. What we end up doing is repeating the same properties multiple times with each browser prefix. Yuck. Another thing we...
![PHP Woot Checker – Tech, Wine, and Shirt Woot]()
If you haven't heard of Woot.com, you've been living under a rock. For those who have been under the proverbial rock, here's the plot:
Every day, Woot sells one product.
Once the item is sold out, no more items are available for purchase.
You don't know how many...
![Fading Links Using jQuery: dwFadingLinks]()
UPDATE: The jQuery website was down today which caused some issues with my example. I've made everything local and now the example works.
Earlier this week, I posted a MooTools script that faded links to and from a color during the mouseover and mouseout events.
So do you know if there is a performance hit with creating an element using this vs creating a string of html?
The right decision is skipping domain entirely if it isn’t hosted on some subdomain (
/path/to/asset), and skipping protocol if it is ((//example.com/path/to/asset)David, rather than str_replace all your (internal)
http://strings withhttps://you should replace them with//– that way your links become protocol-agnostic — a more future-proof solution.Why don’t you use the
search-replacefunction in WP-CLI?Why not remove the protocol completely?
//davidwalsh.name/would default to whatever protocol is used in the address bar.I agree that
//would be better but some RSS feed readers usehttp, othershttps. I’m asserting complete control.