Leaderboard

+1 ! That is the main reason why I am too afraid / too busy to start using rock migrations right now. I understand that in the end it can save you a lot of time but you have to start somewhere and it seems that all the field administration/creation will be done from the migrate.php instead of clicking around in the backend (the normal way) from then on. I mean the typical use case for me would be the following scenario: During site development I do all my field/template creation and settings in the backend. Adding fields to templates, edit the field in template context, etc. etc. Then the site goes live. THEN the client wants something new on the site or wants to change things. This is the moment where PW development becomes a little painful. You have to alter fields or add some new on your local dev environment and test it. Then you have to make all those changes on the live site again. You COULD however replace the database on the server (which includes all the new stuff) but what if other changes were made in the meantime on the live site? Like new articles, new subpages...

https://processwire.com/modules/lister-native-date-format/ is great for formatting lister dates, by the way. You can configure preferred default format for native date fields and switch format on the fly ?

No pain! Its just a question of the workflow. At some point or another you would have to do all things from the migrate.php instead of going through Setup->Fields->Add. It's just different way of approaching things... how can I describe it... it's like a more professional, developer-style approach. I personally am a fan of frontend editing, where you can see what you do and where you click. Sometimes this is safer to use but none the less it will slow you down after time. What I like about RM is that it only takes a few moments to do lots of things once you are familiar the RM syntax. But at first it will resolve in a bit of trial and error and some people (including me) might be afraid to start using it in a finished and complex project. That does not mean that I never want to use RM. The opposite: Your recent video here answered a few of my questions I had before so now I want to try a few things out.

Thank you guys for the input! I appreciate the explanations. ...and that's exactly the reason why RockMigrations exists. Or you write the things you do in migrate.php and just upload that file... $rm->createField('mynewfield', 'text', [ 'label' => 'I am the field that the client wanted to have', ]); $rm->setTemplateData('home', [ 'fields' => [ 'title', 'mynewfield', ], ]); Is that really too much to ask? Seriously. What is the pain here? Is it that you don't know the settings? That's why I added the code section to copy&paste. I'm not trying to convince you here. I'm trying to understand. I know it would be nice to have a "copy current field & template config" button. But I'm afraid it's not that easy and it would be a lot of work for me to build a good solution while it would be really easy for you to just learn the basics of RM and simply write some lines of code. (And not to forget: It would make you a better developer as you'll quickly become more efficient overall and you'll learn a lot about PW which would help in many other situations as well!) Let me know if you find something.

@wbmnfktr I'm not using @bernhard’s tool but you could go this way to have your initial migrate.php: $rm = $modules->get("RockMigrations"); $excludedFields = ["admin_theme", "pass", "permissions", "process", "roles"]; $fieldsCode = []; foreach($fields as $field) { if(in_array($field->name, $excludedFields)) continue; $fieldsCode[] = $rm->getCode($field); } $fieldsCode = "\$rm->migrate(\"fields\" => [\n" . implode(",\n", $fieldsCode) . "\n];"; $excludedTemplates = ["admin", "permission", "role", "user"]; $templatesCode = []; foreach($templates as $template) { if(in_array($template->name, $excludedTemplates)) continue; $templatesCode[] = $rm->getCode($template); } $templatesCode = "\$rm->migrate(\"templates\" => [\n" . implode(",\n", $templatesCode) . "\n];"; And export $fieldsCode and $templatesCode in a file. Regarding the verbosity, it unfortunately boils down to how PW generates the export data. You could be pretty agressive and skip all falsy values but you might get unexpected behaviour.

It's hard to get started. It's either me or missing parts in the documentation. Not only writing the necessary code but to grasp the whole thing. I started using it and already broke a minimal setup with it - due to trial and error. So I'm learning. I probably won't need a real and fully supported GUI for that. These code hints do the trick for me know, even though they are quite verbose. Yet it won't work for most of my existing projects as I had to deal with so many fields and templates. That's were something like an initial-migrate.php file would come in handy. That's the part that's probably the most interesting for some of us as most migrations become difficult due to the missing feature that tracks necessary changes made across fields and templates. Writing each and every field and template in migrate.php feels and is super slow for me right now. Using the backend to create my fields is so much faster still. I can't image doing it for large projects to be honest. Maybe after practicing and working with RockMigrations for a longer time or after wrapping my head around it. I still feel I miss something yet I can't really say what's missing to fully understand it. Sure. But that would probably end in a ProModule of some kind and with a more broader approach in some aspects. Still we could talk about that and try to find out how this could be possible. ?

It's not configurable, since the module config doesn't show system fields, but you can add them permanently with this little snipped for site/ready.php: <?php namespace ProcessWire; wire()->addHookBefore('ProcessUser::execute', function(HookEvent $event) { $process = $event->object; $process->showFields = array_merge($process->showFields, ["created", "modified"]); }); For changing the date format to something more precise, you can hook into the lister: <?php namespace ProcessWire; wire()->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { $page = wire('page'); // Only continue if we're actually listing users in the backend if($page->process !== 'ProcessUser') return; $lister = $event->object; // Assign whatever date format you like $lister->nativeDateFormat = 'Y-m-d H:i'; });

In that case it's pretty straight forward: Create a new field of type "Integer" for holding your allergen number, I'll call it 'allergennumber' here Add the field to the template for your allergens Assign a number to the existing allergens in page editor In the configuration of your page select, on tab "Input", field "Label field", select the "Custom format (multiple fields)" option In the "Custom page label format", enter "{allergennumber} {title}" Your checkboxes will now show numbers. Now for the automatic part for new allergens. Let's assign the highest existing number plus one to every newly created page with template allergen. For that, I'll assume that the template is named "allergen". The PHP code goes into site/ready.php and is executed every time before a page is saved: <?php namespace ProcessWire; wire()->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Adapt the template name to your naming if($page->template->name !== 'allergen') return; // Only fill the field allergennumber for new pages if(! $page->isNew()) return; // Let's get the allergen page with the highest existing number $maxNumPage = $pages->findOne('template=allergen, sort=-allergennumber'); // Just in case we're starting from scratch, handle the first allergen page $maxNum = ($maxNumPage instanceof NullPage) ? 0 : $maxNumPage->allergennumber; // Increment by 1 and set the new page's allergen number $page->allergennnumber = $maxNum + 1; });

Do you already have the numbers in the pages (as a field) that you show in the selection? Because you can change the label field in the input tab (from the page select field) to "Custom Format" and also display multiple fields.

No, not all. Only all the things that should be the same across all your setups ? That's a small but important difference. You can still use the GUI if you want to. But that means that you need to apply those changes manually to all other instances of your project as well. The thing is: Those changes are really really easy once you get used to it. 90% of the time it's setting the 'label' property or the 'columnWidth' setting of a field and adding fields to templates. Using the snippets for VSCode is definitely a huge help. Without them creating fields would be a little pain ? If anybody knows how that feature can be ported to other IDEs let me know! But if something is very complicated using RockMigrations you can still use the old-school way of making those changes manually! For example you could create some fields on the remote system and create some pages, then pull the database changes to your local development and just add all the easy stuff to migrate.php PS: Many of the settings I do not know by heart as well. But it's most of the time quite easy to find them by hovering the inputfield: PPS: I'm quite sure that finding the setting and writing it to migrate.php is faster than doing that manually on local dev and then replicating that change on the live system. It get's even better once you use multicursor in your IDE to set for example 3 fields to 33% width!

Thank you! Will give it a try again. Update: Sorry, I was in hurry. I just saw you made a video for me. This is like VIP support ?

It's because of a bug in TextformatterHannaCode.

In case you are looking for a nice and easy replacement for Pages2PDF as you might face problems with it due to PHP 8 - this might help you to get started and helped me today to get a site up and running again. Thanks to @bernhard for this module. <?php namespace ProcessWire; // file: templates/invoice.php $pdf = $modules->get('RockPdf'); $pdf->settings([ 'mode' => 'utf-8', 'format' => [210, 297], 'img_dpi' => 300, 'default_font' => 'DejaVuSans', ]); // Pseudo header $pdf->write(wireRenderFile('pages2pdf/_header.php')); // Footer $pdf->set('SetHTMLFooter', wireRenderFile('pages2pdf/_footer.php')); // Body content $pdf->write(wireRenderFile('pages2pdf/invoice.php')); // Styleshee $stylesheet = file_get_contents('pages2pdf/pdf.css'); $pdf->write("<style>$stylesheet</style>"); // Actions $pdf->show(); In this example I re-use my already existing pages2pdf-templates and even CSS. It's a super simple PDF, so I really don't have to deal with page margins and such in this case. So you might want to read the docs of mPDF and RockPDF to get this working in your project. There is a lot more you can do in terms of settings and such which can be found in this post for example:

The fields- is very nice to know. This would actually do what I was expecting when adding my fields to a template. But I also understand why it doesn't by default when just using field. In regards to the question you have shown in the video, the user was actually asking a bit more. Something I asked myself as well. Let's say I want to start using RockMigrations within one of my projects it would be nice to have a migrate.php file that contains already all fields, templates and fields in templates with their settings. With that file I could copy the migrate.php file over to a new instance, make my changes and run the migration. With this in place I could clone my existing structure of templates and fields right into a totally new and clean installation. Right now I have to copy the code hints from all of my 100 fields over to the migrate.php and that's something I'd probably never do unless really necessary. For now I would export all fields the PW-way and import them in the project. The same for the templates. If I remember this correctly you had a demo of exactly that functionality in the past somewhere. RockMigrations was watching for all changes that were made and wrote it into a file. Maybe it was in RockMigrations1 or a proof-of-concept. I don't know.

Nice work @bernhard, I'm gonna try RockMigrations soon.

Hi guys, stumbled over this tool to see your breakpoints in a much more neat way (compared to the default browser development tools) It is opensource and can find it here: (i am in no way affiliated) just want to share it. https://github.com/julienagullo/rwdKit Four ways to see it in action, goto this url: https://open-source.jagullo.fr/rwdkit/ 1) resize your browser window 2) click on the devices icon on the bottom right 3) drag the blue bar on the right side 4) use the arrow buttons on the bottom How to use it: Import library plugin: (remove the scripts on production server) <script src="jquery.js"></script> <script src="jquery.rwdkit.js"></script> Initialize the plugin to generate the breakpoint detector in a specific container or the whole document. $(function(){ $(document).rwdKit(); }); $(function(){ $('body').rwdKit(); }); $(function(){ $('.container').rwdKit(); }); Happy developing

Last week we released ProcessWire 3.0.210 main/master and it's been a very smooth launch. No new issues have appeared and all upgrade reports have been good so far. If you haven't yet upgraded I'd encourage you to. Last week's post covered a lot of what's new, in case you haven't seen it yet. Also be sure to check out the ProcessWire Weekly coverage of this new version. This week I've been focused on getting caught up with some client work but there have also been a few minor commits on the dev branch, with more on the way. I hope that you have a great weekend!

Question to all of you... What about a setting that enables PageAutoSave O N L Y when in PreviewMode? I play a lot with Page Autosave + Live Preview but sometimes I'm just tackling my daily tasks and the auto-save feature is (kind of) too much as I start writing but can't finish the text due to a phone call, "writer's block" or my empty coffee cup. Yet the content was entered, saved and is available on the frontend for page visitors. Luckily only within a side project at the moment but still. I could enable the feature only for unpublished pages but most of the content that gets edited is already published and therefore live-content. I'm almost missing a setting like "enable autosave only when livepreview-window is active". What do you think?

server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com; root /home/forge/example.com/public; index index.html index.htm index.php; charset utf-8; # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files # ----------------------------------------------------------------------------------------------- # Block access to ProcessWire system files location ~ \.(inc|info|module|sh|sql)$ { deny all; } # Block access to any file or directory that begins with a period location ~ /\. { deny all; } # Block access to protected assets directories location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) { deny all; } # Block acceess to the /site/install/ directory location ~ ^/(site|site-[^/]+)/install($|/.*$) { deny all; } # Block dirs in /site/assets/ dirs that start with a hyphen location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* { deny all; } # Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ { deny all; } # Block access to any PHP-based files in /templates-admin/ location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP or markup files in /site/templates/ location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP files in /site/assets/ location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ { deny all; } # Block access to any PHP files in core or core module directories location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any PHP files in /site/modules/ location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any software identifying txt files location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ { deny all; } # Block all http access to the default/uninstalled site-default directory location ~ ^/site-default/ { deny all; } #Amplify dashboard location /nginx_status { stub_status on; allow 127.0.0.1; deny all; } # ----------------------------------------------------------------------------------------------- # If the request is for a static file, then set expires header and disable logging. # Give control to ProcessWire if the requested file or directory is non-existing. # ----------------------------------------------------------------------------------------------- location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires 15d; log_not_found off; access_log off; try_files $uri $uri/ /index.php?it=$uri&$query_string; } # ----------------------------------------------------------------------------------------------- # ProCache Rules # ----------------------------------------------------------------------------------------------- set $cache_uri $request_uri; if ($request_method = POST) { set $cache_uri 'nocache'; } if ($http_cookie ~* "wires_challenge") { set $cache_uri 'nocache'; } if ($http_cookie ~* "persist") { set $cache_uri 'nocache'; } # ----------------------------------------------------------------------------------------------- # This location processes all other requests. If the request is for a file or directory that # physically exists on the server, then load the file. Else give control to ProcessWire. # ----------------------------------------------------------------------------------------------- location / { expires -1; try_files /site/assets/ProCache-b3d534d...d/$cache_uri/index.html $uri $uri/ /index.php?it=$uri&$args; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } access_log off; error_log /var/log/nginx/example.com-error.log error; error_page 404 /index.php; location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_index index.php; include fastcgi_params; } location ~ /\.ht { deny all; } }