bernhard

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).

I thought you only "need" mutagen on mac and you don't need it on windows if you are using WSL? I'm on mac + mutagen and I'm happy with that setup 🙂 I think @dotnetic is on windows + WSL?

So it's something that Ryan would have to add as an option to the frontend editing module?

Hi @Stefanowitsch ALFRED uses PW's frontend editing which uses jQuery for the modals. I'd love to have a better solution, but that's what we have. Can you try to disable loading of jQuery in Alfred.js and see if that maybe fixes your issue and maybe it works with the version that you load on your frontend? Then I could add a setting to not load Alfred in the frontend if the frontend already uses jQuery. Also try to use the same version of jQuery that the backend uses.

I solved this by renaming the field instead of moving content. In this case this was the even better (as more performant) solution, but I'd still be interested if anyone knows another way of doing this!

Have a look at URL hooks! https://processwire.com/blog/posts/pw-3.0.173/ Oh, and welcome to the forum 😉

Hey @FireWire the error does not come from block markup, it comes from the {alfred()} call, as the error message tells. Alfred needs a json to get all block settings and it should look like this in the source code (don't use the devtools here): Also look into the console - it should log the element with the wrong alfred json. Once we know the json we can see how to fix it.

Hi @elvina can you try the latest commit of the dev branch? I have added it to RockFrontend as it's only +270kB

Hi everyone! Today I had to move some data stored in a repeater field to another field. I searched the forum and found an admin action by @adrian and came up with a new method in rockmigrations that can copy or move repeater items to new fields and/or new pages: https://github.com/baumrock/RockMigrations/blob/ad59425831c74e32034035afa9d2276f398cc2be/RockMigrations.module.php#L3536 Now I realised that there is a problem: The way this works is it creates new items and then removes the old items. But that also means that IDs change 😮 And I have referenced those repeater items from somewhere else. Does anybody have an idea of how to do that?

?

Hey @FireWire sorry for the trouble. I don't have any experience with this field and I have to focus on RockCommerce until December, so don't expect a quick solution. From your request it looks like you have a load of data sent, so I guess this is related to your post saying that you had to increase the max input variables setting of your server? When using the Frontend for editing this is not an issue. Can you confirm that? Can you also confirm that when clicking the "edit this block in a new window" on the backend it is possible to edit the block as expected? ...Because I'm thinking of maybe adding an option for blocks to prevent direct editing and only show a button to edit them in a modal popup. I think that could solve such issues in a common way.

I've also seen this before and it's really annoying. I don't think it's specific to RPB, or is it? What I found out is that it seems to be related on the zoom value of the browser. For me things rendered nicely at 100% but not at above. I'd be happy for any pointers what could be the reason for this.

Actually none of both. I just changed how fields created by RM can be referenced as class constants. Before it was like this: RockCommerceFields::myfield Now it is like this: RockCommerce::field_myfield

RockMigrations v6.0.0 I'm really sorry, but I had to introduce a breaking change if anybody already adopted the new config migrations. It's unlikely, because this addition was only 10 days old, but I bumped to v6.0.0 to be safe. If you have not yet used config migrations you can just update without issues.

I think they show up if your block has vSpace settings in the info() method. If you remove them I think they should not show up.

@nurkka RockShell can run without PW, but not all commands. Most need PW to be installed, but often that's just necessary (because it makes no sense without) or convenient (because it's harder to develop something without having PW magic on board). What you describe makes sense and it is definitely on my list. If anyone finds time to add this I'd be super happy to add it.

Thx for the explanation! A huge motivation of RPB was to get rid of the workflow that you show here, because in TinyMCE you have no control over how large your image is, what the final aspect ratio will be, etc, etc. That can lead to severe design issues, for example because clients make it look nice on desktop, but they forget to think about all other screen resolutions. With RockPageBuilder we as developers/designers take care of that and the client just uploads content and provides the text. It's still not an easy to solve problem sometimes, but imho it's the better approach.

Sorry, I still don't understand. But I do not let my clients add any pictures inside TinyMCE fields, true. When I need Image + Text for example, then I create a block Image + Text with one image field and one text field.