Recently Browsing 0 members
No registered users viewing this page.
Skip the "Add New" dialog page on Page Tree and elsewhere and go directly to the resulting page that shows all page fields right away. Page creation is now improving from being a two-step to becoming a one-step process.
When only one Template can be selected: Skip the intermediate "Add New" dialog page by adding a GUID or other temporary page name that is later renamed. Show the final editing page so user can start editing all fields right away On Save: Page name is renamed with title When multiple Templates can be selected: Ask user to select Template on clicking New (before leaving the Tree Page). Then use the "one Template" flow above. (I am aware why the Page Name is needed.)
we started our first Processwire driven project in my new company and for the first time, I was working on one site with more than 2 colleagues on the same site.
It didn't take long for us to stumble across some problems when multiple developers work at the same time, conflicts with updating the database on vagrant machines, like duplicate entries for page IDs, errors when setting up fields and stuff like this. We ended up working on a dedicated database server, that we linked to our vagrant machines and most of the problems were gone, but the performance of this constellation is really bad compared to our first approach with database running on vagrant machines.
I already tried to find a solution in the forums but I couldn't find anyone with problems like this.
So I was wondering: how do you manage projects with multiple developers on vagrant machines in a git-based workflow?
Alright. So I'm converting a site I already have to Processwire (really enjoying it so far!). I wanted to convert the previous tables that I had data in to Processwire pages. But I'm wondering what the optimal way to structure pages would be.
So basically, I have three main tables.
Users (and all accompanying information)
Items (and all accompanying information)
Aquariums (each user only has 1 aquarium. Currently, user_id is a FK)
Fish (type of item. Aquariums may have multiple fish)
Aqua_settings (Things like lightness, temperature, etc)
So in my current setup, there are a lot of Foreign Keys. I could accomplish essentially the same thing by using the Page Reference field.
Alternatively, I could make fish and aqua_settings both be children of Aquarium. I could differentiate by doing $aquarium->children('template=aqua_settings'); or something.
So my question is...should I be using the Page Reference field or structuring the pages as children? (Or are both equally fine depending on how I want to go about doing things)
By Martin Muzatko
Hello! I am using ProcessWire for a good three years now already, and I am really happy with the flexibility it provides.
There is one thing though that bugs me. For a recent project, I need lots of templates.
I already have a site/templates folder polluted with a package.json, yarn.lock, node_modules, errors, .eslintrc, .git and my entire build setup.
I read into other posts covering this topic about having a sub folder for templates. Because even with the non-template files stored somewhere else, the template files are still too many. Unfortunately, they also discovered that this is not possible:
Sub Directories for Templates
Should all template files put under site/templates folder
What are your ideas?
I already thought about having a page field, that defines the template path from a dropdown, but with this I would only reinvent an already almost working wheel.
Thank you for your inspiration.