Leaderboard

You did an 100% exact description of RockMigrations. Really, that's exactly how it works.

I've been thinking about this and I think any declarative configuration system should be extremely conservative about removing any data from the database. One way of handling this would be to have a separate location in the config for listing out the names of templates and fields that you explicitly want to remove. If an install contains a field or template not in the configuration or in the removal list, it would simply ignore it. Another approach would be to ignore any field or template not in the config, and provide a separate "cleanup" function that could be triggered with a button in the admin or a cli command. This would go through and remove any fields or templates that are not listed in the config. While the config files could be updated automatically as changes are made in the admin interface, I think that any outside changes to the config files should require a manual sync and not be applied automatically. A notice in the admin could alert the superuser that the config file contains unapplied changes and then they could click a button or use a cli command to apply the changes. The algorithm for adding new fields and templates should first check for the existence of each field and template by name. If one is missing, it should proceed to create the field or template and with its name and type (but no other settings). After that it can go back and apply the settings for everything, at which point dependencies between fields and templates should resolve without issue (family settings, page fields that reference templates in their settings, etc.). I've been tempted to try working on a module for this for a while now and was close to having a project that required it at work that would allow me to invest the time into it. That project is currently stalled but may still come about at some point at which point I could try working on this if someone else hasn't already gotten to it.

That's quite an expressive post, @bernhard! I am actually a pretty slow driver. My Renault is no racing car, and that's because I never wanted to race) And when I need to go a long way (like, to the mountains), I actually try to take a train, so I can have some (root?) beer and yes, chips, along the way and not exhaust myself driving. So you're right - at least in describing me) To my defense, I can say that I actually did install your... car... in my remote testing... garage. And now I am testing how it is showing itself in a... no load situation. But you're right - I (we?) could go faster out of that garage to the mountains (I would rather go to the sea, but nevermind))) Getting rid of those comparisons... yes, I am kind of picky here, as migrations / versionable config is something that can easily break things. ProcessWire is a really author's project, so I am used to be inclined to choose 1st party solutions. But I've already read the source code and tested in a few different ways. Long things short - agreed, I need to get in you car and step on the gas))) Will do so and report back! Still this topic is about something similar, but a bit different than migrations - another way to store configs. So it interesting to me see how things go here. And, as always, Ryan's say on this is a big thing to me. And he still didn't answer in that issue).

@thetuningspoon I completely disagree, because that is farther removed from the goal of having a declarative dec config and closer to the territory of migrations. You don't want to give the system a list of instructions on how to build the correct state, you want to have a declarative list of configuration values that describes the correct state. Getting there happens under the hood. Similar to the difference between declarative or functional programming and imperative programming - you only describe what to do, not how to do it. The system can compare the list of fields in the config and in the database, add and remove fields as needed, and update config values. Combined with version control, this allows you to go back seamlessly to any previous state, revert changes to the declarative config etc, which is something that migrations struggle with, as mentioned. I understand the hesitation to have the system outright delete anything that's missing from the config, but that's just a combination of not going 'all-in' on the declarative config, or not embracing some important workflow changes along with it. You want the config to be the single source of truth for the state of the project, independent of any existing installation or database. If you take an existing 'base' state (for example, tracked in version control as a database dump of an existing installation) and only include changes relative to that base state in your config, you're not there all the way. You want the config to include everything, every field, template, setting, installed plugin, etc. This way, a new installation (for example, a staging environment for a specific feature) can ideally be created with a single console command. Once you have that, you don't have to worry about having the system delete fields that aren't in the config, because deleting a field from the config requires the same amount of effort and has the same visibility in your quality control pipeline as adding one. The rest is just a question of workflow. Changes to the config should be tracked in version control, and merging those changes should require an approved pull request (if you're working in a team). Deleting a field is just as much of a change that is visible in the PR as adding one, since you will see the deleted field config in the PR and make sure that this is really what you want to do. Once you have a solid workflow in place, you can confidently delete everything that you no longer need, because you know you this change will go through review and quality control, and you can get it back through version control if you really need it again in the future. Of course, mistakes still happen. Turns out the client still had some vital data in that field you removed? Well, that's what backups are for. The first step in every deployment script should be a backup. Yes, absolutely. Though in a perfect world, changes to the config are only made in development environments, tracked in version control, and then deployed to the live site (after any staging environments in between). Pulling the config and applying it should be done as part of the deployment script. This way, there is rarely a need to have a button in the backend that applies the config (though this is still useful for development). The more you can automate deployments and get rid of manual steps, the better. This allows you to work in smaller iterations and get features out faster and with more confidence. The Phoenix Project is a great read on that subject!

RM1 had support for RepeaterMatrix so it would likely just be copy&paste: https://github.com/baumrock/RockMigrations1/blob/1ee9f9eb4afaf83529bcedf443b31dd63a5403c8/RockMigrations1.module.php#L1336-L1384 So if you think RockMigrations is missing anything why don't you stop complaining and start asking me if it is already possible or if I can implement it? Why do you think that? ----------- Sorry, but I have to say I'm getting a little pissed with you guys talking about migrations. It's like you were sitting in front of your TV eating chips and watching a documentary about mountains. And you say: "Wow, that views are so great. It must really be awesome to see that in real life! I've dreamed about that for a decade (yep, quoting you here @Ivan Gretsky ? But I don't mean you exclusively with the protagonist in that story )." And then I tell you: "I built a car. It stands in your garage. You simply have to get into it, learn how to drive and 5 hours later you are there! It's great, I'm going there all the time and it's such a great experience and once you've been there you'll never want back. Ah, forgot to mention: You can take my car for free!" And you: "Oh, well... Thank you... I totally appreciate that. You know... it's just... driving a car?! I've never been driving a car... And... You didn't say anything about the car-radio... Does it even have a radio? You know, it's so important to me, because I always hear the news on radio!" And you continue eating chips and watching TV... Me: "You'll learn how to drive in 10 Minutes. It's an automatic car. The previous car had a manual gear shift, but the new car that I built has automatic gear shift, so you really just need to sit in, steer the wheel and push the break or the gas pedal." You: "Well... I'm afraid I could cause an accident! That's really kind of you, but I'd much more prefer if there was a train to that mountains! That would be great! I'm sure the one that builds the train thinks of everything that I need. A radio. I could even take my Laptop with me and watch TV during the ride. I'd be the first to buy a ticket for that train (yep, quoting again)!" You continue eating chips... Me: "Sure, I was also afraid when I first drove a car. But believe me: It's really not hard! And you can go really slow at first and of course, you don't start driving that car on a real street! You go to a big free area where no obstacles and no people are so that you can't hurt anybody or yourself. I have even made a video about how to drive the car." You: "Ok wow, thank you, I have to try that!" You eat the rest of your chips. --- one month later --- Me: "Did you drive the car already?" You (eating chips and watching docs about that great mountains): "Oh... well... yes... I tried... But it does not work. I think I'll wait for the train to be built!" Me: "Ähm... Why? What is wrong with the car?" You: "Nothing... it's just... it is too complicated for me. It's for sure great if you drive cars daily like you do. But for someone like me it's too complicated. It would be much easier to go by train. That would be so great, that mountains look so awesome. I'd love to go there one day." You open a new bag of chips. -------------------- Get your *** up and stop eating chips! Watch that movie and get into that car! Go to a free and safe area and practise. Once you did that I'm happy to hear feedback how the car could be improved. Maybe we need to add cruise control. Or maybe we need to put sunglasses in the car. Or maybe we need to place a sticker on the outside of the car that says: "If you want to drive that car you have to enter on the front seat where the steering wheel is. You can't drive this car from one of the back seats." Or maybe you say "I've tried. I drove the car two hours, but it was terrible. It was loud, it was exhausting. I was not able to watch TV while driving." That's fine. If that is really what you want, then the car might not be the best choice for you. But one of my points is: We have that car already! The train would have to be built. If it is only about you not being able to stop watching TV and eating chips you could also pay someone to drive the car for you. Or you could pay me to add a self driving mode into that car. And for the noise: I'm happy to get those reports and then we can decide if it's something to take care of (to make sure the car does not explode while driving) or if it would be enough to just use oropax until the car get's its silent driving mode. Another point is: I know that it sounds totally great to get into the train, continue watching TV and eating chips and arrive relaxed at the mountains. But you can't go anywhere else. With the car you have the flexibility to go anywhere. And you can go on top of the mountain whereas on the train you'll arrive at the train station and you have to go the last mile by foot. So jump into that car and stop asking for a train by pretending that there is no other way to go to the mountains! Do you get my point? I'm not against having a train to the mountains. But @thetuningspoon's message is like saying "I have thought about it. To go to the mountains we'd need a vehicle that can carry passengers. We'd need an endurance of at least 6 hours, because the mountains are 5h away. It should drive forward by default. Going backwards should require an extra step of caution because it might be more dangerous to push back with that vehicle." Me: "Yeah, you are describing my car." You: "Hm. I thought more of something like a train..." --- So if you don't want to ride that car for whatever reason: Please start describing your train properly and add notes what should work differently to the car that we already have and why. PS: Read the title of this thread... "Build a vehicle to go to the mountains and add gps tracking". Did I already say that my car has gps tracking??

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!

This is my first multi-lang site and client, bless his cotton socks, has chosen to have the site in at least 10 languages. Have figured out many things but Chrome is not playing nice. The default lang is English UK (lang url code is 'default' or 'gb'). On some langs, esp English US (lang url code is 'en-us') and Japanese (lang url code 'jp'), it's flagging the pages as "dangerous - could be phishing". All works fine in Firefox. Questions: 1. How to stop Google flagging valid lang pages as dangerous? ANSWER: Use the language code NOT the country code in the URL, eg English US = en-us (not just 'us') and Japanese = ja (not 'jp'). 2. On langs that don't follow the 'English' convention of text LTR, how do I set alternatives in the HMTL? eg Japanese is 'top to bottom, right to left'. Have done what I can in the CSS using logical properties (eg margin-block-start, padding-inline-end, etc) ANSWER: Add the language name as a class in the body tag then set the writing mode in CSS, eg: /* japanese */ body.japanese { writing-mode: vertical-rl; min-height: auto; overflow-x: auto; } HTH psy

Glad you figured it out! Is this documented somewhere or did you find this by trial and error? They flag you just for some url segments?!

Hi everyone, Hi Chris, A few days ago, I manually integrated the @virtualgadjo changes. So we have a new release for the version on the repo 3.0.200: https://github.com/v-maillard/pw-lang-fr/releases/tag/v3.0.200 For the rest, I created a dev branch. It is on this branch that I started to push modifications concerning the dev version of ProcessWire (currently 3.206). The ongoing work is visible here: https://github.com/v-maillard/pw-lang-fr/compare/master...v-maillard:pw-lang-fr:dev?diff=split Have a nice day, Vincent

This is a double full circle for me. I started using TinyMCE, then migrated my custom stuff to FCKEditor (when that's what it was called). Then when I came to PW Tiny was still the default, then it moved to CKEditor and now we're going back to Tiny :)

Just updated the first post with a new preview video for the Style Panel feature. Let me know what you think.

A ProcessWire Fieldtype storing files in a customized location, outside the web root. This module is primarily useful if you need to store sensitive data which should not be accessible directly from the web. Normally, ProcessWire stores all files under /site/assets/files. Direct URL access to these files can be restriced by setting $config->pagefileSecure = true. Still you need to make sure that your template permissions are setup correctly. If something goes wrong, those files could be accessed from outside. GitHub: https://github.com/wanze/FieldtypeSecureFile Modules Directory: http://modules.processwire.com/modules/fieldtype-secure-file/ How does it work? After installing this module, you can create a new field of type SecureFile. Enter your configuration under the "Details" section when editing the field: Storage Location Enter a path outside the web root where the files are stored. You need to create the directory manually. Also make sure that the user running the web server has write permission. Roles allowing to download a secure file Users with a role selected here are able to download the files if a download is requested via the API. Allow Download in Admin If checked, users having a role selected above can download the files when editing a page. I needed this functionality for a recent project, so I created this module and thought to share it, mabye this is useful for someone else Consider it beta, I'm using it on one site but I'm sure it could be improved here and there. Feel free to suggest additional features! Cheers

Have you had a look at RockMigrations? You get the best of both your worlds: Easy migrations + version control...