Leaderboard

In the past I had used the old version of RockMigrations for some simple tasks like adding fields and templates which turned out to be huge time saver. But only just recently I started to use the new version and to discover the possibilities of this tool in more depths. And what should I say, I am really amazed. Once I had grasped the core concepts and, with @bernhard's help, had learned how to use it in a more structured way and in different contexts, it turned out to to be an even bigger time saver. I hate repetitive tasks. Adding fields and templates and fields to templates and configuring labels / access rights etc for fields in the template context in PW is a pleasure when using the GUI. But it is still a repetitive task. With RockMigrations I can have definitions of these fields / templates and fields in template context in a single file and reuse that. In a matter of seconds I have my reusable base structure available to start off a new project. Adding new structure through the GUI in a staging environment and then having to replicate it on the live sytem through the GUI. Repetitive task again. Pushing a migration file to the live system and running the migration. Again in a matter of seconds. Writing migrations wherever I want is also a great feature. Be it inside site/migrate.php or inside a newly developed module, it doesn't matter. RockMigrations will find it and do its job. At the beginning I wasn't sure how to define different field types with all their different properties. RockMigrations comes with VSCode snippets that make things easy. Or you can create a field in the GUI and then just copy/paste the code for the migration from the GUI to your migration logic. So however you prefer to create your fields, RockMigrations has you covered. This post may sound like an advertisement. But I just wanted to express how happy I am after having made the decision to spend some time to learn how to work with this module. That time was definitely well spent. Big thanks to Bernhard for creating this and releasing it as a free module.

Hello all, I have released RockFrontendTailwind, an extension module for RockFrontend. It extends Bernhard's module and adds an installation profile for site development with Tailwind CSS. Obviously RockFrontend is a required dependency for my module to work. This module aims to give you a quick start with a Tailwind based project. What RockFrontendTailwind does: A folder "rockfrontendtailwind" will be installed in site/templates. That folder contains all the configuration files needed to get you started with a webpack-based build pipeline for JS and CSS with webpack tailwindcss postcss with postcss-preset-env (for autoprefixing) babel (for transpiling) So rather than just building the CSS with Tailwind, the build pipeline also takes care of transpiling your Javascript based on configuration in a .browserslist file. Of course, the setup is opinionated. But people who are comfortable working with webpack can easily adjust / extend the configuration to their liking. The default configuration watches your JS and CSS files and compiles them into site/templates/assets main.css and main.js by default. All paths are configurable through a .env file. Live reloading during development is not part of the webpack configuration since this is handled by RockFrontend already in a very efficient way. Also a _main.php file including a very basic boilerplate for a typical setup will be placed insite/templates. It includes examples on how to render your JS and CSS assets. More detailed instructions over at github. Adding new profiles to RockFrontend through your own modules is quite straight forward thanks to the clear structure in @bernhard's module. RockFrontendTailwind can serve as a boilerplate. The only important thing is that the "profiles" folder structure remains the same. The module is currently in beta but runs very stable. It will eventually be released as an official module in the directory soon. If you want to give it a shot, I shall be happy to hear your feedback. If you are looking for a standalone webpack build pipeline with webpack-dev-server, you might want to have a look at https://github.com/gebeer/tailwind-css-webpack-processwire-starter Happy Coding!

Hi at Gebeer, really thanks for this write up. I followed lately the posts about RockMigrations and the other Modules of Bernhard. Didn't really know how to start or apply with them. Thanks to your writing it gives me a wider perspective and motivation to jump start.

Hey @gebeer thx for that great message, really happy to hear that ?

Just to clarify... I didn't want to make repeaters bad. RockMatrix is based on repeaters and it is absolutely great (for flexible page building). But what I found is that Repeaters are not my first choice when it comes to storing data. For example I've built a survey tool where I saved all the votes in a repeater field of the survey template. That sounded good because every vote belongs to the survey and in the admin gui you can easily inspect all the votes and you can easily loop through all of them via foreach($page->votes as $vote)... So far so good, but then I needed to do complicated calculations and it turned out that would have been a lot easier and more efficient if all the votes had been pages under one parent. Selectors would have been easier, calculations could have easily done in SQL rather than looping all the results in PHP (because you need the parent/child relationship which is easily available in PHP/in memory but not so easy to get from the DB/SQL). What I said might not be 100% accurate and there might have been good solutions even with repeaters, but I had troubles back then and I now have to tools to display all kinds of page data easily and in a great way using RockGrid. Because that's the other side of the coin: If you store everything in pages under one parent it might need a little more thinking where and how you present things. That's obviously easier with repeaters...

@kongondo Firstly, great work. I am watching all about the development od padloper 2 from the start a in looked very promising. Finally, the time has come that I need to create new e-commerce site. How is it with implementation of additional payment gateways? Is there some abstract class for that, or what it be too difficult to implement solution on my own based on already implemented gateways - stripe, paypal?

I have used both and now just use this one on new projects. They both work fine in normal circumstances (and are easy enough to just temporarily install and play with), but @Robin S's is simpler with less to go wrong - I had a few problems with @kongondo's in a multi-instance environment (which I think are fixed). On the other hand @kongondo's has a slightly more feature-rich GUI. You could always build your own simple module rather than just use hooks if you want more than the basic RuntimeOnly and want control over the code - I forked this module to include a custom Fieldtype in my ProcessDbMigrate module. As @bernhard says, it all depends what you are trying to do.

I'd be very interested in some details and explanations on this ? I've been working with forms quite a bit and sometimes things where a little unclear to be honest. For example sometimes I had to do a $this->trackChange('value') to make my inputfield module save anything. While I found a way to make it work it would be nice to better understand the inner workings of the whole process ?

Celebrating 250 commits since Jan/2022 ?

RockFrontend got some really cool updates over the last days thx to some inputs from @gebeer! The latest additions improve SVG rendering and finally I found a way to get rid of the need to add |noescape to every alfred() call in latte files ?? SVGs You can use the render() method to write SVG markup directly to your template file: // latte // icon is in /site/templates/img/icon.svg {$rockfrontend->render('img/icon.svg')} // php echo $rockfrontend->render('img/icon.svg'); You can even provide variables to replace, so you can create completely dynamic SVGs with custom rotation angles or colors etc... {$rockfrontend->render('img/triangle.svg', [ // replace the {rotate} tag in the svg markup 'rotate'=>45, 'color'=>'blue', ])} // add the replacement tag to your svg file // img/triangle.svg <svg style="transform: rotate({rotate}deg); border: 2px solid {color};">... PS: You can also use $rockfrontend->svg('img/triangle.svg') if you want ?

The new version looks good @bernhard and I am very tempted to give it a proper try. However, I have been using my own ProcessDbMigrate module successfully on a number of projects and it is serving me pretty well (and the change in approach would be quite radical). Although the two are quite different in methodology, there are some similarities in that my json files have similarities to your yaml files (btw, not quite sure what advantages yaml has over json in this context - json has coped so far). My module is still very much alpha as something this complex does need extensive testing and bugs do crop up (as well as the need to extend to handle additional field types etc. - the recent version 0.1.5 has been updated to include FieldtypeRepeaterMatrix). Sometimes I think about re-engineering it to use RockMigrations methods rather than the current native ones, but that does lead to some head-scratching. For example, my module will handle uninstallation of migrations (provided they have not been conflicted by subsequent changes) - I don't see how RockMigrations does this (reverting the code would leave the database unchanged?). Also I can attach hooks to run on installation (and uninstallation) to handle any data changes related to the migrations (e.g. say field 'name' is split into 'first_name' and 'last_name', the code can populate the new fields when the installation is run). I assume that RockMigrations can handle that too (at least for the forward install), but not quite sure how. I know you have commented in the past that you don't like my approach (although I'm not sure of the precise reasons**) but I think it is a valid alternative and I would like to somehow get the best of both worlds. ** I can see that using Git to handle conflicts has some advantages. My module has to include its own conflict management which works but has not been tested in a multi-developer environment. Mind you, I can envisage semantic conflicts that might arise which Git would not spot - separate modules changing the same field for example.