Jonathan Lahijani

Nice play on words there. -- In the article you mentioned you could modify your tables to InnoDB by exporting, doing a search/replace, then re-importing. You can also do it like this: <?php namespace ProcessWire; // assuming this script is in the pw root dir; backup your database first, just incase! include(dirname(__FILE__).'/index.php'); $query = $database->query("SELECT table_name FROM information_schema.tables WHERE table_schema='{$config->dbName}';"); foreach($query->fetchAll() as $row) { $table = $row[0]; $database->query("ALTER TABLE $table ENGINE=InnoDB;"); }

I've put in a feature request for this on GitHub: https://github.com/processwire/processwire-requests/issues/207

@gonzz I think the Pageimage Assistant module might help here. At least it did for me when I wanted to convert PNG to JPG, which was helpful in my use-case for a particular site because I wanted to keep the lossless PNGs, but serve JPGs. Not sure what the support for TIFF is. https://modules.processwire.com/modules/pageimage-assistant/

WireHttp might be one solution. https://processwire.com/api/ref/wire-http/

Note: I believe WireCache is the successor of MarkupCache (which is unofficially deprecated?). From this blog post (April 2015): https://processwire.com/blog/posts/processwire-core-updates-2.5.28/

I'm in the middle of uploading them. They'll be perfected by the end of the day.

If you have access to the site files (via FTP or similar), you could reset the password with a script. Here's a recipe that you can modify accordingly: https://processwire-recipes.com/recipes/resetting-admin-password-via-api/

I put in a request similar to that here several weeks ago. Ryan had some justifiable concerns with it: https://github.com/processwire/processwire-requests/issues/137

ProcessWire 3.8? I must be using the wrong Github repo.

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(); }