bernhard

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.

No, I'm recommending DDEV, but it should not matter as it should work either way.

Hey @Atlasfreeman I'm a little confused. Why did you post this in the RockPageBuilder forum? MagicPages are a feature of RockMigrations. Do you use any of the features of MagicPages? If not, you could just remove the use MagicPage statement (line 11 in HomePage.php). Maybe that's already enough to fix the issue, then do a modules refresh and then maybe try to add it back again if you need or are unsure.

Hey @herr rilke thx for your interest. Unfortunately nobody else showed interest so it looks like a video would not be interesting to a lot. I did that as well, but what I don't like with that approach is that if you move a block you have to adjust all classes of all blocks which is tedious. My approach works similar but different 😛 I use a dedicated block type solely for the color. This block sets a custom runtime flag (like $site->bgColor) and all blocks then add a custom class based on that bgColor flag's value. So once I have a color block with setting "muted" all following blocks might get the class "bg-muted", for example. Then when the next color block comes up it might set the bgColor flag to "primary" which would tell all following blocks to add the class "bg-primary". Now the challenge is to make that work with spacings and with frontend editing. On frontend editing the problem to solve is with sorting blocks, because classes come from php and sorting is done on the client with JS. So you need to add a little js to adjust classes once sorting happens. In my project this is done like this: // section color updates on sort document.addEventListener("rocksortable-added", (event) => { let sortable = event.detail; sortable.option("onMove", (e) => { setTimeout(() => { let el = e.dragged; let container = el.closest("[sortable]"); let children = container.children; let colorClass = null; // loop all items and update color classes for (let i = 0; i < children.length; i++) { let child = children[i]; // don't change class of dragged item if (child.classList.contains("sortable-drag")) continue; // update colorClass on every rpb-color block if (child.classList.contains("rpb-color")) { colorClass = child.getAttribute("data-col"); continue; } // update colorclass of element if (!colorClass) colorClass = "white"; child.classList.remove("has-bg-white"); child.classList.remove("has-bg-muted"); child.classList.remove("has-bg-primary"); child.classList.remove("has-bg-secondary"); child.classList.add(`has-bg-${colorClass}`); } }, 0); }); }); For block spacings I've switched my approach from PHP based calculations to CSS based calculations. The trick is to only use margin-top for blocks, because then you can define different margins for blocks based on the previous block like this: .bg-white + .bg-muted { margin-top: 20px; } This way you can achieve a lot of flexibility in your design with very little complexity in code. Hope that helps!

Yes that's all you needed to do 🙂

Hi @nurkka thats a good question 🙂 I'd love to have some kind of migration feature for RockPageBuilder content, but unfortunately it's not there yet. What is already there is an API for blocks, so it's already quite easy to work with block data from the API (https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/). What I usually do in such situations is to always create content on the live site. This is the single source of truth for content. When using RockShell all content changes to your live site are just one command away: rockshell db:pull production But if you have lots of content it might be worth to write a simple script that uses the block api. Or maybe others have some creative ideas as well?

I can remember that the first time installing DDEV was also a little hard for me as well. But it only has to be done once and it has definitely payed off! Good luck 🙂 Oh and if you have troubles reach out to ddev on their git repo. They are extremely fast and helpful!

I think it will, but I don't know. So please either create an issue for ProcessWire to ping ryan about that or just mark this topic solved 🙂 One day I'll have to rebuild the frontend and backend of RPB to use the same tech and then this issue will also be fixed..

There you have it: For me the experience was terrible 😄 But I have been using there services years ago. I can only remember having had troubles when deploying applications because they had some weird permission setups. At least that was weird to me back then. I might judge differently nowadays. But I'm happy with Hetzner (for VPS hosting).