This feels like a stupid question that i should know the answer to but i don’t.
So I’ve made a couple of pull minor pull requests to the core which may or may not get implemented. A couple of them fix bugs and one is a good but selfish feature i needed. Obviously I’m not making them for fun, i made them because they impact work i’m doing for customers.
So how do i handle it between now and when it does (or does not) get purchased into a release? On my development machine it’s easy…i just run my fixed code. But on a production site it’s not only bad practice but impractical to modify the core.
we do monthly releases.
Make sure there’s a clear explanation in github and consider adding color about the reason why it needs to happen and the testing you’ve done around it and it’s likely Andy will pick it up.
We want to incorporate submissions, it’s easy to be hesitant because of the unexpected side effects that frequently happen when changes have been made in a void.
I know that doesn’t answer your in between question, but hopefully it helps.
Beyond that, we try to use the composer install process and overrides.
@frz just to be clear i wasn’t complaining at all. You guys do an amazing job and i’m impressed by your commitment and the platform itself. There’s some really talented contributors in this community and i was just curious how they handle the workflow because the way I’m doing it now isn’t sustainable. I’ll look into composer overrides.
Didn’t you guys do an open house like 10 years ago? are you every going to do it again? I live like 10 minutes from your office.
Let’s say you’ve submitted a pull request to the Concrete repository.
Let’s say that pull request has been accepted, but a version of Concrete that includes it isn’t available yet (or the core team hasn’t accepted the pull request but you believe they will).
If really need that change before it’s available in a new Concrete version:
a. If you install Concrete using the ZIP file:
I would simply apply the change (since the update process is manual, you have control over what and whe when gets updated)
b. If you install Concrete with Composer, then you can use composer patcher (it’s already installed by Composer since it’s a dependency of Concrete):
In the main composer.json file (the one located in the root directory of your project), simply add patches to extra, along with the version of Concrete you’re using and the path to a patch file in your project.
For example, let’s say you need the changes from pull request 12846 for the 9.5.0RC2 version of Concrete you’ve installed.
{
"extra": {
"patches": {
"concrete5/core:9.5.0RC2": {
"Fix bodyHTML of mail service": "patches/concrete5/core/9.5.0RC2/mailservice-bodyhtml.patch"
}
}
}
}
The description Fix bodyHTML of mail service can be whatever you like, it’s just used to show a message when that patch gets used.
When you run composer install or composer update, you will see this patch applied automatically.
The nice thing about this approach with Composer is that it’s all automatic: the patch will only be applied to the version (or versions) of Concrete that you specify in your composer.json file.
Installing Concrete via Composer is rather easy (though it does require some familiarity with terminal commands, and you’ll need to have PHP and Composer installed on your computer).
if you want to develop locally and you need a configuration for your local development environment that differs from the production instance, create a file .env containing
CCM_ENVIRONMENT=development
run composer update to download Concrete and all its dependencies
configure the webserver so that the root of your website points to the web directory
no worries, my apologies if I came off defensive - I was on my way to reply to an unrelated post and was probably bringing some exhaustion to the table you didn’t deserve. Certainly didn’t mean to sound glum. Just offering some tips on how to get Andy’s attention in a sea of tickets over there on github.
Yeah we did a “ConCON” back before the pandemic, I’m going to say in 2018? Crazy its been that long. We don’t work out of those offices in Oregon City any more, we went fully remote when the rest of the world did and haven’t ever considered going back. That said, it was great seeing so many community members and buying folks some beers. I dunno what level of interest that would really draw these days, but I do love the fact that we’re part of this big family.
@mlocati THANK YOU for the detailed notes. I’m rolling out a new customer’s site this week and will give the approach you outlined above a try. Thanks for taking the time to write it. This seems like a great way to handle the situation.
@frz doesn’t surprise me that y’all are all remote now. As much as i drive through where it was all the time i’d never taken the time to look to see if it was actually there. I don’t imagine there’s that many local folks in the community post-pandemic people are weird about travel not to mention it’s expensive. Although it works better when you bundle it with training.
