bernhard

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 🙂

Or something like this? (untested, never used) <If "%{HTTP_HOST} == 'foo.ddev.site'"> Options +FollowSymLinks </If> <Else> Options +SymLinksifOwnerMatch </Else>

Both directives are needed if you have symlinks in your setup, which will be the case if you use RockMigrations deployments for example. If you don't have any symlinks I guess you could remove them, but I'm not sure if anything else needs them. I don't have any problems with DDEV.

Hey @olivetree thank you for your question. ProcessWire is totally open to how you structure your frontend or where you put which kind of markup, that's why the short answer would be "wherever you want". The RockFrontend site profile loads the _main.latte file for every request. Before that, it loads the template specific file, eg home.php or basic-page.php So for example you could place your code snippet in _main.latte, then all blocks would be rendered on every page. If you only want to render rockpagebuilder for basic-page pages, then you could add this: {if $page->template == 'basic-page'} {$rockpagebuilder->render()} {/if} Does that help?

Are you wondering about how this module is different to ListerPro? Have a look at this thread:

Hey @olivetree thank you for your question. I think in terms of use cases you can do quite the same with both modules. (See note at the end) The main difference between both modules is how/where data is handled. ListerPro handles all data on the server side, which means there is basically no limit in terms of scale. Pagination etc. is all done by the backend (php) and only small chunks of the data are sent to the client. With RockGrid, on the other hand, all the data is sent to the client at once and that data is then handled by the client. That has the drawback that you might hit limits earlier than with ListerPro, but it has the benefit that sorting and filtering is done on the client and produces instant results. There is no need for any ajax requests, no waiting for receiving the data, etc.; Another benefit of using RockGrid is that you have unlimited possibilities in HOW you present your data. The downside is that you need to define all that with a mix of PHP (the data selection, basically just a PW selector) and JS (the visual part). With ListerPro you can build your data listings via GUI with just a few clicks. That means that you are very limited in terms of visually presenting data. In terms of scalability RockGrid should be fine quite far, though. Users reported good results with grids having 75 columns and up to 150.000 rows! That's a lot. It always depends on the device though, but I've never had tables with 75 columns and less columns means more rows possible. If you have a look at the demo image of RockGrid: How would you build that with ListerPro? BUT: ListerPro will show page actions by default and you will not have to do anything. With RockGrid every piece of the representation comes from code, so if you need page actions you need to add code to do so (there are helper functions there, but it's more work than with ListerPro). Oh, I almost forgot 🙂 You can use RockGrid as an Inputfield as well! For the RockCommerce module I'm using RockGrid to select the variations of a product. You can filter by variation name, then select all options of the variation by clicking the variation column, then deselect single items that you don't need by clicking on the option column: So RockGrid can not only be used for similar use cases like ListerPro but also for use cases that you have used page reference fields in the past. 😎 I'll have to write better docs and make a video about it, but I wanted/needed to release it as it is a dependency for RockCommerce and for that module you don't need to create any grids on your own, you just install the module and use it. That's why for RockCommerce the RockGrid docs are not a necessity. It's a really powerful module and it has gone a long way. 🙂 Does that answer your question? PS: Oh and here is an example how you can use it for more complex input scenarios, like adding prices and doing calculations on the fly: That's also very different to what ListerPro offers 🙂

Nothing yet. We are still not at the stage where we really need that feature 🙂

Ok thx. The reason why it ends up in main.css is actually 50% because of RockPageBuilder and 50% because of RockFrontend. RockPageBuilder adds something like this: rockfrontend()->styles()->addAll('/path/to/all/blocks'); This will tell RockFrontend to add all .less files to the main css file. You can tell it to rename this file, have a look here: https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/asset-tools/ That means using the SCSS module it should also be possible to use ->addAll() and just place all .scss files in the block folders and let the module compile it to one file. Do you understand what I'm trying to say? 😅