Leaderboard

@kongondo @szabesz @horst A completely automated deployment enables continuous deployment as well as a number of other workflows. Being able to rollback to a previous version is part of it, but it's only one of the benefits of version control, and probably not the most important one. It's all a question of how much your workflow scales with (a) the amount of work done on a project / number of deployments in a given timeframe and (b) number of people on your team. For me, the 'breaking points' would be more than maybe one deployment a week, and more than one person working on a project. There were many different approaches mentioned in the previous threads – migrations, cloning the production database before any changes, lots of custom scripting etc. But those all break down if you're starting to work in a team and get into workflows centered around version control. The key to those workflows is that each commit is self-contained, meaning you can rebuild the entire site state from it with a single command. For comparison, here's how I work on a Craft project with my team, following a feature-branch workflow. I may work on the blog section while my colleague works on the navigation. We both have our own local development environment so we can test even major changes without interfering with each other. Once my colleague has finished, they commit their changes to a separate branch, push it to Github and open a pull request – including any template changes, translations, config changes, etc. I get a notification to review the PR. I would like to review it now, but I'm working on a different feature right now, have a couple of commits and some half-finished work in my working directory that's not even working at the moment. No problem, I just stash my current changes so I have a clean working directory, then fetch and checkout my colleague's branch from Github. Now it only takes a couple of commands to get my environment to the exact state the PR is in: composer install (in case any dependencies / plugins have changed) php craft project-config/apply (Apply the project configuration in my current working directory) npm ci (install new npm dependencies, if any) npm run build (build frontend) Most of the time, you only need one or two of these commands, and of course you can put those in a tiny script so it's truly only one step. Now I can test the changes in my development environment and add my feedback to the PR. Keep in mind that the new 'blog article' entry type my colleague created with all it's fields and settings is now available in my installation, since they are included in the config that's commited in the branch. Now imagine doing that if you have to recreate all the fields my colleague has created for this PR manually, and remove them again when I'm done. Now image doing that 10 times a day. By the way, everything I was working on is savely stored in my branch/stash, but is not interfering with the branch I'm testing now. This is the benefit of a declarative config: Everything that's not in the config gets removed. So even if I left my own work in a broken state, it won't interfere with reviewing the PR. With migrations, you'd have to include an up and down migration for every change, and remember to execute them in the right order when switching branches. Any manual steps, no matter how easy or quick they are, prevent those workflows at scale. Automatic deployments also makes your deployments reproducible. Let's say you have an additional staging environment so the client can test any incoming changes before they hit production. If you do manual deployments, you may do everything right when deploying to staging but forget a field when deploying to production. With fully automated deployments in symmetric environments you'll catch any deployment errors in staging. That's not to say you can't introduce bugs or have something break unexpectedly, but by removing manual steps you're removing a major source of errors in your deployments. I can one-up that: zero clicks. Automatic deployments triggered through webhooks as soon as a PR is merged into the main branch on Github. Deployment notifications are sent to slack, so everyone sees what's going on. A branch protection rule on Github prevents any developers from pushing directly to the main branch, and requires at least one (or more) approvals on a PR before it can be merged ? You're clients never ask you to undo some change you did a while ago? Not because of some bug, but because of changed requirements? In any case, if your version control only includes templates, but not the state of templates/fields that those templates excect, you won't be able to reverse anything non-trivial without a lot of work. Which means you don't get a major benefit of version control. Going from commenting out chunks of code because 'you might need them later' and just deleting them, knowing you will be able to restore them at any time, is really enjoyable. Having the same security for templates, fields, etc is great. Fun story: I once implemented a change requested by a client that I knew wasn't a good idea, just because it would take less time than arguing. Once they saw it in production, they immediately asked me to revert it. One `git revert` later, this feature was back in its previous iteration.

I've not participated much here, since I feel there are more knowledgeable folks here already, but a few quick (?) opinions/experiences: I would love to have an easy way to migrate changes for fields and templates between environments, and version control all of that. I've had cases where I've made a change, only to realize that it wasn't such a good idea (or better yet, have a client realize that) and off we go to manually undo said change. Sometimes in quite a bit of hurry. These are among the situations in which an easy rollback feature would be highly appreciated. I do like making changes via ProcessWire's UI, but at the same time I strongly dislike having to do the exact same thing more than once. Once is fun, but having to redo things (especially from memory, and potentially multiple times) is definitely not what I'd like to spend my time doing ? I've worked on both solo projects, and projects with a relatively big team. While versioning schema and easily switching between different versions is IMHO already very useful for solo projects, it becomes — as was nicely explained by MoritzLost earlier — near must-have when you're working with a team, switching between branches, participating in code reviews, etc. I'll be the first one to admit that my memory is nowhere near impeccable. Just today I worked on a project I last worked on friday — four days ago! — and couldn't for the life of me remember exactly what I'd done to the schema and why. Now imagine having to remember why something was set in a specific way years ago, and if altering it will result in issues down the stream. Also, what if it was done by someone else, who no longer works on your team... ? Something I might add is that, at least in my case, large rewrites etc. often mean that new code is no longer compatible with old data structures. For me it's pretty rare for these things to be strictly tied to one part of the site, or perhaps new templates/fields only. Unless both you and the client are happy to maintain two sets of everything, possibly for extended periods on time, that's going to be a difficult task to handle without some type of automation, especially if/when downtime is not an option. Anyway, I guess a lions share of this discussion boils down to the type of projects we typically work on, and of course different experiences and preferences ?‍♂️ As for the solutions we've been presented with: I've personally been enjoying module management via Composer. Not only does this make it possible to version control things and keep environments in sync, it also makes deploying updates a breeze. As I've said before, in my opinion the biggest issue here is that not all modules are installable this way, but that's an issue that can be solved (in more than one way). While I think I understand what MoritzLost in particular has been saying about template/field definitions, personally I'm mostly happy with well defined migrations. In my opinion the work Bernhard has put in this area is superb, and definitely a promising route to explore further. One thing I'd like to hear more is that how do other systems with so-called declarative config handle actual data? Some of you have made it sound very easy, so is there an obvious solution that I'm missing, or does it just mean that data is dropped (or alternatively left somewhere, unseen and unused) when the schema updates? Full disclosure: I also work on WordPress projects where "custom fields" are managed via ACF + ACF Composer and "custom post types" via Extended CPTs + Poet. Said tools make it easy to define and deploy schema updates, but there's no out-of-the-box method for migrating data from one schema version to another (that I'm aware of). And this is one of the reasons why I think migrations sometimes make more sense; at least they can be written in a way that allows them to be reverted without data loss.

Personally, I'm not after versioning, I have never ever reverted back my code/database to any previous state, anyway, as I only sometimes copy some useful lines from a few hours ago and that's it. I painstakingly test all what I implement, so in the end there is no need to revert to anything. What I am after is being able to edit templates/fields in the admin on my local machine and when I am done (and has already thoroughly tested all my work), I would like to push all the changes to the production site with a single click. That's it.

I wish this would be an option here but Ryan on the other hand has his stand here. Which I really like somehow even it doesn't fit my needs at all. On the other hand I have seen already solutions from others - no, they aren't public and I won't tell who, but - and they look promising. Really promising like something I know from the setups I worked with years and years ago in a J2EE/Oracle setup. That was a super-portable setup. A few files managed through Tortoise SVN and all and each instance was updated. I would support a broader pool to make developing open source software and extensions for PW more a business than a hobby. I know too many free/OSS devs that can hardly make a living, therefore my goal is more about a sustainable pool for plugin devs. SURE... this is still absolutely nothing like planned or thought through... yet... there needs or should be some kind of benefit for plugin devs. I already donated to some here for their work. Just because their software made my life and projects way easier. While talking about that, I still plan to build up kind of a pool for developers in my projects. Still in progress... yet.

We also use the Keyword field more as a reminder of keywords we're targeting a particular page at - especially as most search engines ignore this data anyway.

This is to keep track of the state of a site's structure independent from the content. To allow changes of fields and templates that have been altered on local or staging to be transferred to the production version without loosing content that was introduced in the meantime. Does this make sense?

PM me if I can share any info that would help get you up to speed. Can share some configs, code, or answer some questions if you need. I spent a lot (a lot) of time on tuning our setup and would be happy to share. Also, snapshot your "perfect setup" on DO before you host anything on it. I have one that is a template for our servers and I can spin one up in minutes. Also gives you some extra confidence with experimenting when you know you can nuke a server and start over with a machine built how you like it.

Now it does, thanks ?. Thank you very much for the very clear and detailed explanation. My confusion is over ?.

Strange - still not attaching the cid to the row. It is in a loop and I know it works as it is also in the data? *I spotted that in the options code it should read plural attrs

You can create a textformatter that adds the <span> to all your links

Great timing then @alexmas I recently updated the demo to actually show the available colours and sizes of variants. I will update the repo soon. Later today, I'll also write some code here to look at since the demo one is a bit opinionated.

Thanks @horstfor enlightening me. Some of the confusion is gone. I still don't get why you would version a field or template (not template file) though ?.

That's my thought each and every time I miss a few weeks of @ryans posts. There is soooo much in PW we don't know but Ryan.

Sure we could trick here a bit with CSS but that would be future-proof at all. Therefore... you might try the HannaCode solution @Gideon So mentioned or otherwise add another layer with just JS. I can't promise anything... but will keep this tough in mind while doing some CSS-work. Maybe... I could come up with something. Shouldn't that be easy? I will look into it a bit more at the end of the week, as I have time then. But I guess there should be something possible. Could you provide a "final result" for what you need or something? Just drop it in my DMs if it's too "confidential" or similar.

I did for way too long. Therefore they don't like me anymore. ? But yes... it's more of a culture to work this way but on the other hand... we all are free-devs with super individual workflows. I can't and don't wanna blame anyone for this. At the end everything was fine*. * 100s of merge conflicts later, with rebase and such things. ?

Holy smokes how did i miss these two!!! so useful!!!! Thanks for sharing you setup, I'm defos going to get on the PageSpeed train too on DigitalOcean and the 7G Firewall looks super usefuly too.

Not really an important update, but I wanted to highlight a new feature in the Console panel that lets you override it's default behavior where it handles and reports exceptions in the results pane. This is generally more convenient, but sometimes it's helpful to see the full stack trace in Tracy's "bluescreen". I've added a new checkbox to enable this. One important thing to note is that the bluescreen breaks the Console panel - to get it working again, you can minimise/hide the bluescreen (down arrow at the top right), or reload the page. I feel like I should be able to solve this so it doesn't break the Console panel, but for now, this is the workaround if you use this feature.

Good news ! I managed to add some good support for ProField RepeaterMatrix. Github link (experimental, use at your own risk!) Todo Only allow possible fields per matrix types in the schema. Add matrix type as names and not as integers. Easier to read. Support for mutations / inputfields. Repeater Depth/Indents -> Need to add feature to FieldTypeRepeater. However I can't share it as a third party module. You have to insert the php file manually. This is due to the static method field() {} not being called from a third party module. Feature request? ? BTW @dadish I couldn't find a way to add invisible types to the Schema during construction. I tried to use the modifySchema hook, but no luck. Could be useful

@Roych , Use hanna code and hanna code dialog in a ckeditor field may fits your need. Gideon

I'm going crazy with this. Looking at the post https://processwire.com/blog/posts/pw-3.0.142/ The picture "says" that options are supported as a field, (see License block) but it does not work for me in any version i tryed in version: 1.48, 1.65, 1.70 If the field is not supported i would not show an image of that type. Am i wrong?

Have a look also to the section on Sub-selectors in that doc. So this should do it: $matches = $pages->find("template=group, children=[my_int_field=0]"); And for the other case: $groups = $pages->find("template=task,parent=[closed=0]");

Could you provide an example of your template code? I ask because of something I did wrong in the past. Some links were static and set within the code itself and didn't come from ProcessWire. So if you set a the href to /impressum/ it will stay the same no matter what language you wanted to use. But if you let ProcessWire do the job like $pages->get('id=4')->url it would/should show /impressum/ or /en/imprint/.