And as we are all lazy, we like generators that scaffold a basic php package layout and luckily there are several out there.
They all differ a bit, so pick your favorite. Continue reading “PHP package generators”
Using your forks of certain packages with composer is actually pretty easy:
Add the repo of the fork to the repositories block of your composer.json, you might need to change the version to f.e dev-master and thats it. Great. Actually.
But there are some traps, especially when you are mentally already weekend bound:
When working in a team, take care that you dont add your fork as a private repo.
This happens when you use the @ notation like ‘email@example.com‘. Its tempting because it will be the clone url on github when you are logged in, which is very likely.
If you do so your team mates will get errors like this:
Symfony’s ParamConverter is a common way to transform some GET param to an entity before your controllers action.
This happens most of the time via type hinting and priority detection kinda magic in the background.
But as magic is often obscure sometimes you need a bit of explicitness.
F.e. when you have more and different ParamConverter per entity you want to name them explicitly.
Then you can use named ParamConverters.
I usually would not recommend deployment via git and running composer on your prod server for several reasons like f.e. the network. I rather believe in builds.
But sometimes its just too convenient :)
In a recent website-project i had a WordPress Blog running next to the main CMS Silverstripe, handling the Blog-part of the site.
Integrating the Blog in Silverstripe (which indeed would have made things simpler) was not an option at the time. The usage of loads of WordPress plugins would’ve made a rewrite a major task, which was out of the budget.
The blog was integrated in the same page layout as the rest of the website. So ideally it would at least share the same Templates for header, footer etc. and would integrate the sites navigation built by Silverstripe.