bernhard

Adding Endpoints to 3rd party modules https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/ajax/#adding-endpoints-to-3rd-party-modules 😉 But of course that means a dependency. Some might prefer that, some might not. Just wanted to mention that the option is there if anybody finds this by coincidence.

Looks like you could also use RockFrontend ajax endpoints: https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/ajax/

Actually the name of this module is totally wrong, because you can not only use it to pick colours, you can also use it for example to pick layout positions - here as an example in a RockPageBuilder block: The code to achieve this: $picker->setColors('site_overlayposition', [ 'top-left' => [ '<svg ...></svg>', 'Oben Links', ], ... ]);

https://github.com/processwire/processwire-issues/issues/2000

Hey @snck thx for the idea. I'm not sure. On the one hand I think it's a nice idea, on the other hand I'm not sure how much it would really help. I'm also having staging + production on the same system and in the rare cases where I have to re-sync staging and production I've always just copied the DB + files over. Given that both are on the same system this is really fast and not an issue. filesOnDemand is built for the case of developing locally where downloading several GB of data might be slow (I have only 30 megabit downloadrate 😉 ) so I only need to download some MB once in a while when I visit a page that did not exist on dev. On the other hand I see room for improvement in synching staging/production, so whoever wants to tackle this, I'm happy to help and add it!

Just use RockMigrations for everything that you add or remove. That's it. Once you push to production RockMigrations will kick in and do everything that you did locally also on the remote system. If you have to add lots of content for whatever reason then just add that on the production site (eg on a new unpublished page) and do a db:pull instead of pushing your local database to the remote.

Not sure what you are trying to say, but that's exactly how the new config traits work. I've added a note about PHP8.2 to the docs: https://github.com/baumrock/RockMigrations/commit/4e776f5185ce19866fd853c87a9acec47f4e7485

I don't know if that could be the reason, but I don't use the host at all any more in my config files. I always use the concept of including different files on my local development and on remote servers. See here: One of the reasons is that the hostname (or in your case the HTTP_HOST variable) might not be available. For example when bootstrapping or calling it from a cronjob. Or the variable might be empty for whatever reason. When including different config-local.php files on local dev and on production/staging you don't have these problems. That would at least be something that you can try.

Hey @FireWire this issue should be fixed in v5.9.2 🙂 Please mark the topic [solved] if it works for you! Thx

Yes I always use underscores. I had problems with hyphens several times. I can't remember any more where exactly, but I remember that avoiding them was the easiest solution. Any sources for that? PW definitely uses camelcase constants like Inputfield::collapsedHidden which I think looks nicer than Inputfield::COLLAPSEDHIDDEN. But I'd be happy to get some links to read.

I'm not sure about this. That should only be the case on regular runtime migrations, but when doing a modules refresh all migrations should fire. I'm using RM Deployments and they perform a backup before each deployment. Is that what you are looking for?

Hey @gebeer thanks for trying out Config Migrations so early 🙂 💪 Same here 😍 The file should not be in /site/modules/Site/RockMigrations/... but should live side by side with Site.module.php! I just had a look into the docs and you are right - the instructions there are like you say. I have to look into what you said tomorrow, but if you have time and read this in the meantime, then I'd appreciate if you could try to create the file /site/modules/Site/RockMigrationsConstants.php and see if that maybe fixes some other of your mentioned issues? Thx a lot! I'll likely do exactly that 🙂 As of 2 days ago we have PHP8.4 released and PHP8.1 gets security fixes only - so I think it would even be fine to have PHP8.2 as a requirement for the module. Any other votes?

I think I don't understand your question, because from how I understand you the answer what I'd do is to just create two commits. v1 / commit: initial version v2 / commit: make it better v3 / commit: make it best But I guess that's not what you where asking for? Or are you talking about release tags? Then have a read here: Or you could also create two or three branches. For example I have some modules that I can't update on some servers, but I had to develop them further for new projects. Then on older projects some issues arise, so what to do? You are on an old commit and the current development state of the module is 17 or whatever commits ahead. "git pull" is not an option, so you can create a new branch for the old version (eg "git checkout -b 'foo.com'" - which would create the branch foo.com) and push your updates there. So you'd have a "main" branch with the module for all current projects and you'd have the "foo.com" branch for the stale project "foo.com"

Glad it was helpful @herr rilke! Yeah that would be possible. Another option would be to solve it with nested elements, so you'd have a "color" container that can hold other blocks (like headline, text, image, etc). Even that would already be possible using RockPageBuilder and @Stefanowitsch did something quite crazy in this regard and hopefully shares it one day with us 😉 But I try to not introduce any kind of multi-level editing for clients. I try to keep things as simple as possible and only add necessary features. But coloured sections is one of them imho.

Hey @FireWire I need the raw Sourcecode not the formatted one from the devtools. In chrome use right click show source rather than inspect element.