Late last year I created an API using Symfony 3 for a personal project, and had the intention of talking to this API via WordPress. Or more specifically, from a custom WordPress plugin. I thoroughly enjoyed building that API. It followed my usual practices of testing with Behat and PHPSpec, and I must have built about 20 or more API implementations now using Symfony 3, so development flew by at a jolly old clip.
Then, this week I had a bit of spare time. Why not, I thought, create the WordPress plugin?
You’re probably expecting a horror story. And if I’d been writing this email at any time before 11am yesterday then you wouldn’t have had one.
Everything was going smoothly. A little too smoothly, considering I have next to no recent experience with WordPress.
All I needed to do was add in a button to the visual editor which, when clicked, would show the user some info in the form of three drop down boxes.
It’s the classic wizard-y type thing: what you select in drop down #1 should filter the available options in drop down #2, and so on. Sounds like something that shouldn’t take 9 hours, right?
At this point I am sure you are thinking: “Lol, that’s WordPress for you, you newb!”
But that’s not fair on WordPress. At least, not directly. The issue I had was with tinymce, an included third party dependency of WordPress.
I won’t rant too much here but why, oh why, would re-inventing the extremely standard select box with a wide range of nested divs and buttons ever seem like a good idea? It frightens me that this code is distributed to the several tens of million (est. 74m+ with a quick Google) WordPress websites out there.
Anyway, as I say I don’t want to rant – I already lost a days worth of productivity to this, but to bring it home I cannot stress enough how lucky we are as Symfony developers to have access to such amazing documentation.
And if that still doesn’t get you the answer you need, a really nice tip is to use github as a Google for code. Try and find someone else’s project who has done something identical – or very similar – which you can *ahem* borrow. Try doing that with a search like “tinymce plugin”, and behold the madness.
This week there have been three new videos added to the site:
First up this week we started mocking things in Jest. Specifically we didn’t want to make real API calls during our tests – for many reasons – instead choosing to mock the real function that would make the calls, essentially tricking our code into thinking that nothing was out of the ordinary.
Mocking in Jest does differ slightly to how you may have mocked before, but is quite intuitive once you see it in action. Just be careful to clean up after yourself (covered in the video) unless you enjoy the unexpected 🙂
One thing that drives me nuts is when I read through the documentation – which if done right, usually makes things look very easy (and therefore encouraging to adopt) – only to be met by real world issues that either are completely ignored in the docs, or found only after a dive through the project’s GitHub issues register.
Now, if your project is anything other than a learning exercise, sooner or later you need to go into production. This brings one particular problem in the front-end > back-end paradigm: we likely don’t want to use the same URL for our API in production that we use in our development environment.
Of course, Webpack has us covered here, though the specific approach is not that intuitive.
But Jest doesn’t use our Webpack config. And is therefore completely unaware of our constants. Arghhhhhhh!!!!
Ok, so in this video we address this – and another problem. This should save you a ton of time if you’re following along, or building a similar project.
Lastly this week we look at Symfony Service autowiring.
This is perhaps the nicest feature of Symfony that I never use.
That said, it is nice to know this feature is available, and not difficult to use at all. In this video I will show you how to use autowiring, and leave you to form your own opinions as to whether you might find this useful.