I’ll be the first to admit that I have trouble with regular expressions. But they’re incredibly useful when used in the right way. For instance, I was recently tasked with finding a way to insert a related podcast into a story node. To do this, I gave users the ability to add a shortcode into the text that would be parsed prior to viewing, so I could inject the necessary HTML.
Sounds simple. The shortcode would come in the form of [podcast id=”1234″]. Great. That’s easy to implement and simple enough to parse with PHP if I can find it in the text string.
preg_match('/\[podcast id="\d*"\]/', $string, $podcastString);
This would work well, right? If you’ve done this type of thing before, you likely have your go-to source to test your regular expressions. I use www.regexr.com for my tests (they have a very clean and easy to use UI). So this will get all the instances of the podcast with the id if I use the /g flag in the regexr tool. But that flag won’t work with preg_match. That’s when I learned about preg_match_all. I know. I should know about this by now, but I’ve never dove into regular expression to any great length until now. So now this work just fine:
preg_match_all('/\[podcast id="\d*"\]/', $string, $podcastString);You can read about preg_match_all in the PHP docs.
Today’s problem came as a result of a Firefox anomaly. It’s one of those problems that comes up after launching because we were too lax in testing. Here’s how it broke down, without going into great detail about the application.
When adding a new activity, the application inserts that entry into the table of current asks and closes. On reload, Firefox was showing old data in those fields, but if the user clicked on a different page and came back to the dashboard, they would see the correct data. Upon inspection, the value of the input was correct. Meaning the browser was replacing the input with what it believed to be good data.
Unfortunately this bug wasn’t caught until production. The answer was simple. We only needed to turn off autocomplete on each of the inputs. This immediately solved the problem.
Add that line to the input and the problem disappeared.
I ran into this issue recently. I wanted a larger version than what’s returned from the basic response API search. The images there are intended for mobile applications and are available at 60 wide and 100 wide. Easy to get those. What are you going to do with it though? Take a look at the size of the largest version returned from the API.
But how do you get a larger version if your web application requires it? It doesn’t mention anything in the API documents.
Hence a bit of search and replace…take a look at this returned url from the basic api search.
Now all you need to do is replace where it says 100×100 with any value. Need an image that’s 400×400 wide? Change the values to equal that and you’re good to go.
A simple php string replace should do the trick. Here’s what I used to get a 200×200 version of the album.
$albumArt = $response->results->artworkUrl100; $albumArt = str_replace('100x100', '200x200', $albumArt);
I received the response from the iTunes search library made by Vinelab