Jonathan Lahijani

If you're looking to do an elaborate a page builder with ProcessWire and don't want to pull your hair out, I highly recommended viewing this video: A couple notes: with the css grid specification, you can assign multiple blocks to the same grid-area but they will overlap each other. I've "overcome" this by combining multiple blocks into a parent div and assigning that instead. pretty easy to do. i didn't demonstrate it, if your blocks have a grid structure within them (like built with flexbox), you can still assign that block to a grid-area. so if your blocks themselves have a grid structure, that's ok. for example, if your css grid layout is 6 columns, but you have a block that has a grid inside of it (built with like uikit's grid that's 5 columns), you can assign that block to the grid-area. with the css grid specification, the flow of the blocks does not have to match the flow of the grid-areas. this is insanely powerful. Enjoy.

Brain dumping here, but on one end of the spectrum, we have good-ole' templates, which is what ProcessWire is all about. Then on the other end, we have these infinitely configurable, drag-and-drop page builders. Popular ones include: webflow.com (arguably the most elaborate) grapesjs (looks like open-source webflow clone that they encourage CMS's to integrate) yootheme pro (a wordpress builder; Yootheme is the company that makes UIkit, so their approach particularly appeals to me since I'm all in on UIkit); it's interesting to see how a pure, truly inspired uikit builder would be imagined, and yootheme pro is it other wordpress builders: gutenberg, divi, beaver builder, + a million others Of course, if you have a site that has highly relational data and templates, PW is perfect, but then there's those one-off pages, or sections within templated pages, that need the flexibility of a builder so the non-coder editor who's editing the page can do what he needs to do. I think these builders need to take the end-user into consideration... with too much flexibility and an editor without a strong understanding of how they work, it's more likely the resulting builder page that has been created is going to be sub-par. The images might be way too big, the fonts may be off, spacing, etc. etc. Honestly, even when I as a web developer use those builders, it doesn't feel right, but perhaps that's because I'm totally biased. I feel having a strong set of components/blocks that each have a bit of flexibility to them via various options is the better way to go if it makes sense for a site. RepeaterMatrix does this perfectly and because it's through RepeaterMatrix, you can use PW's API to query things if need be. The trade-off is doing column layouts is a bit trickier (not impossible), it's not 100% visual/drag-and-drop, and you have to create a defined list of blocks/components/matrix-types (which is another way of setting up some expectations of what is and isn't possible).

I'm hoping my example made sense in the context that you explained it. I'm not sure if by 'contactors' you mean actual people.

/contactors/ (contractors.php) bob smith (contractor.php) ... /companies/ (companies.php) acme corp (company.php) ... /jobs/ (jobs.php) 123 main street (job.php) ... /specialities/ (specialties.php) electrical (specialty.php) plumbing welding ... - create a page field (asm) called 'contractors'; assign it to 'company' template (as well as the 'job' template? not sure if that's what you meant) - create a page field (asm) called 'specialties'; assign it to the 'contractor' template - create a page field (single select) called 'contractor'; assign it to the 'job' template I'm not sure if you also need 'specialities' on your contractor template, but you did mention that as well. The approach I outlined is the collection-y way of doing it, like a traditional webapp framework.

option 1: w/ 'owner' selector (as mentioned in blog post) $items = $pages->find( "template=architect, " . "architects.owner.parent.name=atlanta, " . "architects.owner.height>1000" ); option 2: w/o 'owner' selector (2 queries required) $architects = new PageArray(); foreach($pages->find("template=building,height>1000,parent.name=atlanta") as $building) { $architects->add($building->architects); } option 3: w/o 'owner' selector but requires a bi-directional relationship field called 'buildings' on the 'architect' template (using the bi-directional approach or possibly PagefieldPairs, or ConnectPageFields): $pages->find("parent=/architects/,template=architect,buildings.parent.name=atlanta,buildings.height>1000"); Hopefully that de-mystifies it. I come across this brain twister once in a while.

I want to set a handful of fields to have the autojoin setting checked via the API, however it's not as simple as: foreach($fields->find("name=myfield1,myfield2,myfield3") as $f) { $f->autojoin = 0; $f->save(); }

Depending on how much you want to change, you can always do CSS overrides. Put this line in /site/templates/admin.php, above the line that brings in controller.php: $config->styles->append($config->urls->templates."admin.css"); Make a file in templates called "admin.css". Now let's say you want to change the navbar color: #pw-masthead { background: #666 !important; }

Patreon is an even bigger offender: https://worldvectorlogo.com/logo/patreon How dare they! But they have a new logo now: https://www.patreon.com/brand/guidelines Ryan must have filed a major lawsuit.

Nice writeup. You could use Page Image Manipulator to convert PNG to JPGs by the way: https://modules.processwire.com/modules/page-image-manipulator/

This is no different from using a CMS like WordPress or Drupal given their architecture. I'd recommend looking at the approach of Roots.io. More specifically reading their Twelve-Factor WordPress App series and adapting it accordingly with your preferred set of tools: https://roots.io/twelve-factor-wordpress/ #6 addresses file uploads: https://roots.io/twelve-factor-06-processes/ Relevant module: Hope this helps!

I went "crazy" quite a few times over all frontend churn as well, FOMO, etc. At the end of the day, use the best tool for the job. Right now, practically all of my needs are met with the following stack: ProcessWire UIkit3 (it's so good; but, but the horror of using UIkits classes in your HTML!) Some PW premium modules: ListerPro ProCache (it's become my build process tool; you can build UIkit3 with it perfectly fine; I'm dumping Node, Webpack, and whatever the "latest" way to do things is) FormBuilder Pulling in whatever packages I need via composer VueJS if needed (loading it via CDN, oh my god the horror!) Digital Ocean for hosting (manually configuring their Ubuntu LAMP 16.04 droplet... takes only a few minutes) If your clients want to use some crappy shared host, switch them to DigitalOcean; it's practically the same price. I develop all my sites on Windows (but technically it's Linux thanks to WSL). No VMs, no Docker (again, the horror of what happens if my server ends up being PHP v7.0.23 and my local machine is 7.0.22!). Simple and reliable 99.99999999999999% of the time. I deploy with a simple shell script (horror! not using Capistrano, Ansible, whatever the latest tool is). Sure, your site won't be able to handle all of earth's traffic if everyone were to visit your site at the same moment, but it'll be fine for 85.7% of the sites you most likely take on. I've built very complex sites with just those tools and I move extremely rapidly while keeping the site client-maintainable! Even if you became Mr. Expert on the latest frontend tools, it's going to change significantly by this time next year and the year after that. Perhaps sit on the sidelines for a bit. End rant.

There's a commercial module for that:

My approach for reliably sending out system-based/transactional emails is to signup for Mailgun.com. It's free if you're sending out less than 10,000 emails per month. It will require you to put a credit card on file. I then use the Swift Mailer module to customize the SMTP settings and such: https://modules.processwire.com/modules/wire-mail-swift-mailer/ Make sure to setup the TXT records as well that Mailgun recommends. For example, if your site uses G-Suite for regular email and Mailgun for transactional emails, then this is what you'd need (refer to what Mailgun tells you upon signup; replace the IP with your server IP address, or adjust accordingly): v=spf1 ip4:123.456.789.123 include:_spf.google.com ~all v=spf1 include:mailgun.org ~all I've found this method to be extremely reliable, quick, painless and I like that the account is not tied to what might be a site's overall email system like G-Suite. It keeps things separate to prevent situations like this. (definitely read that link)

Building on what PWaddict said, you could optimize the code just a little bit more, like this: <?php foreach ($p->moments->find('yearofmoment=1969,sort=month') as $moments): ?> You can then remove the conditional you have: <?php if ($moments->yearofmoment == 1969): ?> ... <?php endif; ?>

For fun, you could also create a wp-login.php file in your PW root directory so that hackbots get confused (or redirected away, or just show a blank page). Here's an example of some random website that implements this technique: http://processwire.com/wp-login.php If you've ever looked at a website's access log files, you'll see that that URL is hit all the time. Easy way to prevent a bunch of 404s.