Leaderboard

I have to agree with you. It feels a bit weird to me, specially the "AR" part, which translates to "air", but I tend to read it as A.R. But that's the brand, and it already existed before the website. The domain name too, was already running with a not very good wordpress. Good thing is, as she came over to deliver some of her products, she commented that she already had some contacts coming from the site and that wasn't happening before. We haven't even started promoting it other than me sharing it on twitter, so this is great news.

The problem: Synchronizing fields and/or templates made on the dev server with the live server is cumbersome. At the same time, there is no version control of fields and templates, which some folks (including myself) see as a disadvantage of ProcessWire. A way to have version control to track changes and replicate automatically would be desirable. There is the template and fields export feature in ProcessWire which has said for ages that this is only a beta version, although I have used it many times without any problems. However, even with this method, it is very cumbersome to reconcile changes between dev and live. You have to remember which fields / templates you created and select them, then copy and paste them on the dev server. This is a manual, cumbersome and time consuming process. Existing solutions: For this reason, several solutions have been developed such as: Migrations by @LostKobrakai https://processwire.com/talk/topic/14603-rocksvn-brings-version-control-to-your-fields-templates/ ProcessWires Template's and field's export function https://processwire.com/modules/rock-migrations/ https://processwire.com/talk/topic/25307-oh-no-not-another-migration-module/ https://processwire.com/modules/auto-export-templates-and-fields/ Other systems like Laravel, Craft, Kirby and Statamic use configuration files (migrations, YAML) to manage fields / templates, which allow to create a state of fields / templates. Since the configuration is done in a file, you can of course manage it with git (or other vcs). By configuring in a file, it is also possible to automatically execute these migrations during a git push through different deploy pipelines like github actions, buddy, bitbucket pipelines and thus you have the desired state on the desired server. Where to go from here? In another post @bernhard showcased a prototype, that uses a YAML-file to create and manage fields / templates in ProcessWire. At the same time he showcased a YAML recorder which writes all changes that are made to templates and fields into a YAML file, which looks very promising. I think a combination of a recorder and a YAML config file would be a optimal solution, at least for me. What format to use for such a configuration file was and has also to be discussed: Update 30th September 2022: Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable. This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement. @bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

Natasha Marques is a desserts chef and chocolatier from Brazil with an international carreer. Now established in my hometown Porto, she's about to open a shop and already shipping her premium line of sweets and desserts. The website is my usual combo of PW with StencilJS frontend with a content blocks approach. Minimal stack of modules: SeoMaestro, WireMailSmtp, and my own block selector module which is a hacked version of FieldSelectFile. The site is only in portuguese, but have a look anyway: https://arbynatashamarques.com/

This week I've bumped the dev branch version to 3.0.194. Relative to last week, there are a few commits fixing minor issues. Last week we covered some fairly major updates and I've not come across any concerning side effects, so figured it's a good day to bump the version. Next week my kids are out of school for winter break so I'll be around but I don't expect I'll have much in terms of updates to report next week, but definitely will the following week. Thanks and have a great weekend!

Thanks I will look into this and if it works I will update this post ?

Not really, since from the beginning it has been PHP >= 7.0.0

Got same problem. I have co clean sessions table once in a couple of days, as it grows enormously. Had same thing with files. Sessions are a headache to me in either way(

I will check and update it when I have installed a local php 8 environment. So do not expect it in the next weeks. But definetly get updated to php 8.

In recent (4.x) versions of ProCache the docblock for ProCache::___allowCacheForPage suggest that it might be a good place to hook to prevent cache file from being created. I'd probably try hooking there and setting return value to false in case a specific env variable is defined (or not defined). Other than that... no obvious solutions here.

Thanks you @gmclelland yours tips works for me with ProcessWire 3.0.184. Just i have written "customstyles" rather than "custom-styles" in step 2. Maybe it will help someone.

Hi! This is a really useful module. I use it to combine some graphics with the watermark option. However today a host of my client updated to PHP 8 und I got a fatal error: Exception: Cannot load the MemoryImage! After donwgrading to PHP 7.4. everything worked again. The host told the client they will switch to PHP 8 next year and only offer paid support for older versions, so it would be nice if I can continue to use this module. Are there any plans to support PHP 8 in the future?

Hi @joe_g Repeaters are actually pages resides under the admin page which is not accessible to roles other than superuser. Gideon

It's on the "Advanced" tab:

I'm not using them day-to-day... that would be such an overhead. But yes, worktrees are some kind of next-level chaos at first. Still sometimes really nice. I used worktrees in some larger projects in which lots of things happened at the same time. So switching from branch to branch, stashing, half-baked commits didn't work out at all. I mapped each worktree to its own virtual host, could switch code bases whenever needed without said things, like stash or commit. Are they perfect? No. At least not in my day-to-day projects. But there have been some projects I really benefitted from worktrees. Still a tiny fraction, but still. I assume it will work out totally different in case you do C/C++, Rust, Go, TS... things like that. At least that's my impression while watching coding session similar to video linked above.

Just got bit by this as well... I realized that there was a massive increase in db rows (from 11k to 19k) so I checked the DB and saw the big sessions table. Found this thread, visited admin > access > session-db and boom - shrink from 19k to 8k rows: What are you guys doing about this? I'm also on ubuntu and have to update several installations I guess... What settings do you use? Wouldn't it be the best if ProcessWire did automatically clear up old sessions on its own independently from the server config?

Hi @joe_g Try add check_access=0 to your selector. https://cheatsheet.processwire.com/selectors/built-in-page-selector-properties/check_access-0/ Gideon

Works great, thank you very much!!

Give the latest version a go. There was one other place that needed the isLocal check removed.

Sorry I missed your second post... Actually something similar would already be possible using RockMigrations. At least for basic setups. I'm not sure how that can work for more complex setups though. I'll try to explain that by an example: Let's say we created a new blog module. We need a blog page (parent) and several blog-items (children): - home '- blog |- blog entry 1 |- blog entry 2 ... This setup could easily be built into a module using rockmigrations: <?php namespace ProcessWire; class MyBlog extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyBlog', 'version' => '0.0.1', 'summary' => 'blog module using rockmgirations', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->fireOnRefresh($this, "migrate"); } public function migrate() { $this->rm()->migrate([ 'fiels' => [...], 'templates' => [ 'blog_parent' => [...], 'blog_item' => [...], ], ]); $this->rm()->setParentChild('blog_parent', 'blog_item'); // --> this sets the family settings for both the parent and the child template - how long does that take by hand? ;) It means that all pages having the "blog_parent" template will create a "blog_item" page automatically when you click on "add new page". Basically the stuff that you set on the family tab of the template. } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means I'm literally defining my config in the module code. We could also have the config read from a config.yaml - that would really be the same (just less powerful IMHO)! The problem arises when you want to make that config customizable. For example you want a page reference field to select the author for every blog post. Building that into the blog module would probably not be a good idea because not every site might need such a field. What I do in such situations is this: I make the migrate() method hookable and create one module that handles all the project-specific stuff: <?php namespace ProcessWire; class MyProject extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyProject', 'version' => '0.0.1', 'summary' => 'module that handles site specific stuff', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->addHookAfter("MyBlog::migrate", $this, "migrate"); } public function migrate(HookEvent $event) { $this->rm()->createField("author", "page", [ 'label' => 'Select the author', ... ]); $this->rm()->addFieldToTemplate("author", "blog_item", "title"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means you can have your blog module that you can reuse from project to project (and improve it and just pull changes if you need to) and you can still customize it the ProcessWire way (which we all love I guess). BUT Now we got a new field on the "blog_item", the "author" field. So the config.yaml of the blog module would change, wouldn't it? I'm not sure how CraftCMS handles such situations? And that's one of the reasons why I think that efforts like this are going in a wrong direction. It sounds intriguing for sure to have something like a "migrations recorder". I'm working or at least thinking about that since 2016. But I simply can't imagine a way that could reliably work in all situations. RockMigrations does. And it does it really well. And it does it for almost 3 years now and has evolved a lot. It's still not perfect for sure. But I don't think that This feels wrong. I'dont know how to explain. I think you have a good understanding of composer and such things. Likely a much better understanding than I have. So if it is true what you are saying, I must be doing a lot wrong in my daily work or at least I must be understanding a lot wrong... Because a lot of my workflows do feel very version control friendly. And I've lately started working in a company in vienna where we work on ProcessWire projects with fully automated workflows. We work in a team. We work on different local machines. We deploy to staging and if everything works (which has been the case 100% so far), we deploy to production with a single click. But maybe I'll change my opinion some day and look back and laugh. Maybe I should just try CraftCMS. Maybe many other fancy new tools. At my company they also work (or worked) with another CMS. They said they liked to be able to define fields and templates in code. They said that was one of the (few) things they didn't like about ProcessWire, because they love professional workflows and automated deployments... But they also admitted, that it was somewhat painful to define fields and templates in the other CMS. They said you have to add pieces of config in that file, then change another piece in another file. And end up changing many files for simple changes. Now they like RockMigrations ? And such comments make me think I am on a right track and we as ProcessWire enthusiasts are not that far away from what you seem to be missing. @MoritzLost have you ever heard someone saying "ProcessWire is great for small websites, but not for larger, more complex ones"? We all know how wrong that is, don't we? That's the way I feel when people here on the forum are talking about missing migration / version control features... PS: I tried to keep this post short and not so emotional. I think I failed, sorry ?

Just in case somebody needs to get the override label in the current language… I did… // Get label in current language echo $templates->get('template_name')->fieldgroup->getField('my_field_mame', true)->getLabel(); // OR directly from the page (no matter how the templates name is): echo $page->template->fieldgroup->getField('my_field_mame', true)->getLabel(); This is a way faster than using translate stings in the template: __("I'm an in english headline, translate me!")

I assume that you know how to show field label on front (there is few options), one option is: echo $page->fields->summary->label; // for field with name "summary" But today I had a problem how to show field label depending on the current page template (example: in template "member", "summary" field label is override to "Personal info"). In that case, previous example will not give you desired result. To get field label in that case, this is what works: $page->getField('summary')->label; // result would be "Personal info" Maybe this is helpful for someone. Regards.

Hello Zilli, you should be able to echo the title of the current language like this: echo $user->language->title; You can set the title of the language under Setup->Languages in the backend. Best, Nils