bernhard

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? 😅

RockForms v2.1.0 Breaking Change: RockForms was refactored to use RockLoaders for loading animations. If you have not used any loading animations in your project you should be safe to just upgrade without issues. If you have any problems let me know in the forum! Added getData() method to improve API usage for multi-step-forms

RockPageBuilder v5.9.1 Added a config setting to prevent loading the frontend styles file as requested by nurkka here Added block type to the API for filtering/finding as requested by gebeer here and updated docs Added new block icons thx to FireWire's post here. Thank you! 🚀 Improved docs about sort/groupSort

RockShell v3.4.0 Added PR #16 from lemachinarbo that improves host checking to support different ports and DDEV env variables; Thank you! 🚀 Added module:create command Added module:install command

RockMigrations v5.5.0 Added PR #65 from lemachinarbo that improves the moduleInstall command; Thank you! 🚀 Added support for config migrations: See docs This update is extremely helpful and from now on the recommended way to write migrations, as this workflow makes circular references a problem of the past! 🥳💪 Added docs about automated releases

RockFrontend v3.23.2 PW functions like wire() or modules() are now available in latte files 😍 That also means that translations via __(...) now work natively! Several fixes and improvements for the AJAX Endpoints feature Improvements to the quite new field() method Improved consent tools

Maybe I mixed something up in my head?! I thought this was solving your problem. If not, could you please describe the problem again and with more details. Steps to reproduce, etc. Thx!

This powerful module has been under ongoing development for several years. The history dates back to the year 2016 🤯 Back then it was built on top of https://datatables.net/. Later I switched to https://www.ag-grid.com/ and finally settled with https://tabulator.info/ to do the heavy lifting. With RockGrid you can display any kind of tabular data on the ProcessWire backend. It helps you structure your code in a way to keep it maintainable and it comes with a lot of helpers that customise tabulator to the needs of ProcessWire. Download & Docs: baumrock.com/RockGrid

Hey @gebeer would be nice to mark this topic [solved] thx 🙂

Hey @nurkka I've added a setting for you some time ago and think I forgot to mention that 🙂 Please check out v5.9.1 and mark this [solved]

Congrats to all of you 💪 Great to see you had a good time 🙂

I also like the "cowboy coding" term, but I want to add that VSCode remote can not only be used for cowboy coding but also for - I don't know how to say - regular tasks! I'm using it on a regular basis to do different things on my servers that I manage. It's great, for example, for editing files that are not part of the automated deployment - eg /site/config-local.php Browsing files, moving folders, searching for keywords in the codebase, temporarily adding something to the codebase, etc.; All of that is extremely comfortable to do with VSCode compared to doing it on the command line. So it's definitely a tool that is worth to have and worth to know!

Hey @zoeck thx that helped a lot. I hacked together an example for you that shows how you can use AlpineJS for that: public function buildForm() { $form = $this; $form->setRockFormsRenderer('UIkit'); $form->setHtmlAttribute('x-data', '{ lines: 2, init() { // update lineData when lines input changes this.$watch("lines", this.lineData.bind(this)); // monitor inputs and update textarea document.addEventListener("input", this.updateTextarea.bind(this)); }, // return an array that we can use for x-for lineData() { return Array.from({length: this.lines}); }, // update textarea when inputs change updateTextarea(e) { // find all .linedata elements const els = document.querySelectorAll(".linedata"); // get their values const values = Array.from(els).map(el => el.value); // join them with newlines const text = values.join("\n"); // set the textarea value to that document.querySelector("textarea").value = text; }, }'); $form->addInteger('lines') ->setHtmlAttribute('x-model', 'lines'); $form->addTextArea('times') ->setHtmlAttribute('rows', '10'); $form->addMarkup('<template x-for="line in lineData"> <div><!-- must have one single root element --> <input type="text" class="linedata uk-input"> </div> </template>'); } The idea is to create a textarea (that would be hidden) that holds the data and to build the UI based on another input via AlpineJS x-for directive:

Nope, it doesn't. This has probably confused many of us 😉 It's a bug. These mails can be ignored. Maybe @Pete can look into it one day?

Interesting thread. I'll add RockMigration deployments to the mix. I'm working on a video about it 🙂 And I'll probably improve the process along the way...

Hey @olivetree my site profile uses NPM to install tailwind and tailwind is used for all the utility classes like "mt-5" or "py-2" etc.; Whenever you run "npm run build" this process is started and it creates a css file that you can then load on your webpage. In my profile this is usually done whenever a file changes (from /site/livereload.php). If you don't modify your markup on your production system this file will never ever change, so you can just upload that file and that's all you have to do. If you don't need to recompile the file you don't need npm on the remote server.

I still don't understand. Could you please describe it with an example from start to finish?

Hey @Sanyaissues thank you very much!! 🙂 Hi @zoeck thank you for your question - I have not had the need for that so far but looking at the docs of your link it looks like a great match. If you only need a simple repeating element it might also be an option to use AlpineJS! What is the exact use case?

Hey @FireWire thx for the message. I think that sounds like we should do another video call 😉 PM...