LostKobrakai

There are various forum topics around no how you can convince customers to use ProcessWire even if it's less known and it mostly boils down on showing the ease of management even for the (most often) unexperienced customers.

For composers vendor folder I'd suggest putting it into the root folder. PW 3.0 does auto include from there and it's basically all the dependencies the site has which is kinda like the wire folder as well.

Page access in the backend is not handled by template access rules, but by the module's config (permission): https://processwire.com/api/ref/modules/get-module-info/

That's not correct. $page and $pages are the only api variables preregistered as local variables. Other processwire api variables are available via the access method in classes: $this->wire('api-name'). And you can always create as many own variables as you like in there. Nobody needs you to use the local variables $pages/$page for the code. They're just there for convenience.

And just to make that one clear, you shouldn't even need to hook anything. This should just work fine by putting this into the custom php code for the field: $contentWire = new ProcessWire('/mypath/to/content/site/', '/content/'); return $contentWire->wire('pages')->find('…'); If you want to maintain the reference throughout the request (not creating the instance multiple times) I'd suggest doing this in the init/ready.php: $contentWire = new ProcessWire('/mypath/to/content/site/', '/content/'); $this->wire('content', $contentWire, true); This does register a new processwire api variable $content for the second instance, available in custom php code like this: return $this->wire('content')->wire('pages')->find('…');

You're correct in that you can just query the other instance. But you should never mix and match pages between instances, because the id's of pages are only unique per installation. I thought you wanted to do that.

ProcessWire is a nice out-of-the-box solution in storing custom content, so you're set in storing those listings or payment information. The actual payment processing does need to be handled either by a 3rd party modules or your custom code and very much depends on what you need there.

I'm sure this isn't possible, as pages are stored by id and the id is instance (/db) dependent.

I fully understand. Hiding the select essentially means the input is unusable if javascript does not work for whatever reason. That's exactly what you want to prevent with any progressive enhancement. It's true, that in the context of the backend it might not be a pressing issue, but I'm not really convinced that showing nothing before js kicks in is much better than showing the original select field. There will always be a layout update.

Chosen is a progressive enhancement for the plain select, which is why it doesn't do anything to the select until it's started by javascript. That behaviour is on purpose.

Your NiceClass does need to be the module class, too. $modules->get() will only ever return module instances and nothing else. If you cannot control NiceClass you can always create a module that acts as an Interface/EntryPoint into NiceClass.

Are you sure it's the db and not any of your php files or incorrect html encoding?

That's mostly because it's not a simple problem to solve at all. Merging of changes happening in two independent systems cannot work simply by clicking a button. There are various ways to make it work, which all come with their own kind of backdraws. With each project having different goals/needs it's a matter if choosing the one giving you the least pains, while helping you enough to make it worth. Also I'm not sure if I missed some beta statement in my modules topic, but it's really stable. Any upcoming changes should only affect the accompanied cli tool. Also I've it in production usage for over a year now with no issues in the latest months.

Just because a page happens to be linked only in the footer it's probably not supposed to be nested in the page tree. ProcessWire does hold pages in a hierarchical structure, which does not necessarily correspond to all the various navigational patterns used throughout the page. I'd just add those pages as "hidden" children of home. Hidden because they're not part of the primary navigation, but the are still direct children of home (think of the breadcrump you'd have for that page). For building the footer menu I'd just hardcode that one in the template or use some of the few menu builder tools available for ProcessWire.

In memory search is only possible if the to be searched element is already retrieved, which means only if you call find on a PageArray. You're calling find on a Page object, which is just syntax sugar for $pages->find("parent=$booking, …") . I'd suggest you using https://blackfire.io/ for profiling. It's the best tool to look into the system I've ever used. With few parts of ProcessWire being called all over the place it requires a bit searching to find the exact part of code you actually can improve on, but it's worth for not needing to guess. To improve on plain query count (not necessarily speed) you go this way: $bookings = $pages->get('/bookings/')->find('room=roomOne'); // 2 queries foreach($bookings as $booking) $roomData = $booking->find('date=' . $today); // n queries // Improved $bookings = $pages->find('parent=/bookings/, room=roomOne'); // 1 query $roomsData = $pages->find("parent=$bookings, date=$today"); // 1 query foreach($bookings as $booking) $roomData = $roomsData->find("parent=$booking"); Edit: Just to add this here. Doing database queries in foreach loops is almost always to be avoided.

I'd try looking for what does change between the first time the directory should be created and the second time. Maybe there are issues on one/some of the parent directories of the cache.

I wouldn't focus so much on the fact that a directory cannot be created, but rather look what might result in that. If that error is happening when the cache file is still warm then it's questionable why there's even an attempt to create that folder.

The error is happening when a new cache file is being created, so it's naturally happening in fixed intervals corresponding to the cache time.

I think in terms of building apis people just look at things like laravel which come with everything included: router, automatic post data parsing for json, rules where to put files and so on. Some things are nice to have like the automatic parsing of json if the post data come in as content-type: text/json, while in case of routing I'd keep that one for people to install manually. There are great 3rd party routers out there, so no need to have one in ProcessWire by default.

Are you sure it's the save that's being slow? I'd first suggest you to measure the timings in that code at various places before we try to improve in the blind. An example on how to measure the timings can be found here:

Maybe a race condition? Two people hitting the cache expiration time at the exact moment?

Language packs are only for backend translation. Frontend translation, while handled by the same system, must be done on your end. Maybe take a look here for more details: https://processwire.com/api/multi-language-support/

Well, the hoster I had that issue with wouldn't even be listed in such a overview. It's a small hosting company of probably <5 people. My client liked the personal support there, but there where only running of the shelf debian with the stock 5.3 just a year ago.

Pagefiles are only supposed to exist in the context of a page and a related field, because lot's of it's functionality does depend on information stored in those objects.

It's not only the users, it's also lazy hosters. In shared hosting environments some hosters only support a single php version per server. So the hoster cannot update because of potential incompatibilities for the users and the users cannot (easily) change the php version, because they're supposed to move their site to a whole different server. In the worst case both don't really care.