bernhard

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.

That's a very cool idea @Klenkes thx for helping me out!! If you guys need any additional classes to make styling easier, please let me know! We could add row numbers or settings name to each row etc.

When using RPB for frontend editing you need to make sure that your websites CSS does not interfere with the modal CSS, which could be the case here. That's actually not specific to RPB - it's how ProcessWire's frontend editing works.

Hey @FireWire I've added the following to RockSettings v2.2.3 public function ___uninstall(): void { rockmigrations()->deleteFields("tags=RockSettings"); rockmigrations()->deleteTemplates("tags=RockSettings"); }

Thx, looking forward to seeing what you build with it 🙂 Thx for the good description! Please check v1.4.2!

PS: Actually what I really want to implement one day is to make it easy to add RockFields anywhere on the page edit. So for example you could place a checkbox for "center headline" directly below the headline text inputfield. That would also make it easy to build your very own settings UI with just regular HTML.

@herr rilke you can already do something similar from the API in RPB. See the docs here: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/settings/#adding-default-settings

Hey @herr rilke I agree that would be nice to have but there are no plans so far to add this (unless someone sponsors it). The problem is that once I added this I'm quite sure the next request is to also support "showIf" and that would make the whole undertaking more complex, as I'd basically have to re-build the whole PW page edit interface... If you want to improve the UI you can either create dedicated fields and set columnWidth settings for them or you could create your own custom inputfield, which is not too hard and has the benefit that you have a new skill that you can use outside of RPB as well. Technically it is already possible as the "settingsTable" is just a shortcut. But unfortunately there are no docs about how RockFields work and I need to work on RockCommerce docs first.

Could you please describe what you are trying to achieve?

I don't understand, could you please be more specific?

Hi @FireWire could be that I forgot to take care of that. I've never had to uninstall RockSettings 😄 But all fields should be tagged by RockSettings, so deleting them should be one line with RockMigrations. Then also delete the template and that should be it?

Great 🙂

Please update to v3.4.1 which updates dependencies because of this security issue with symfony/process:

The problem with wire()->modules->refresh() is that it might trigger another migration which could cause an endless loop. That's why there is rockmigrations()->refresh() which sets the "noMigrate" flag before doing the modules::refresh and then resets the flag after it is done.

Hey @gebeer thx for your question. Interesting that I did not experience this issue... But I have added a check that should reset the cache if the path changes. Please try v1.3.0 https://www.baumrock.com/releases/rockicons/

Well we all do try/error and that's a valid workflow for most situations but not for describing problems or asking for help. Your problem description so far for me is like: Please provide step by step instructions what you did. Often this already leads to an AHA moment and shows you the solution or what went wrong.

@olivetree you have to be more specific with your questions and with your descriptions otherwise I can't help you. I don't know what "worked" means. Did you get output? Did you get no errors... What did you do? Where did you put the echo statement... I have no idea what that means. I don't understand, sorry. That's definitely not necessary and it is definitely not complicated or tricky. This is a problem with the module directory. It does not grab the version number automatically and I'd have to update every single module for every single update that I push, which is not an option. I'll ask Ryan for a fix, thx.

Great. Please change the topic to [solved] if you find time, thx 🙂