LostKobrakai

The good reason here is being a content-management system and not a layout-factory of sorts. It's there to store content, while being concerned as little as possible about whichever way the content will be served to the user. This is up to the developer to decide/implement. In fact it's rather the opposite. E.g. drupal is recently trying to shift more towards being a potentially headless cms, which is not coupled to any kind of output strategy (html+css is only one possibility). With the shift to more and more content being served over multiple channels at the same time (website + api / website + mobile app / …) it's also needed to have this freedom. But as I said it always depends on the individuals situation. If you need something to click together the layouts in the backend ProcessWire might not be the best fit.

ProcessWire is missing a CLI installer for a long time. You might want to take a look at how wireshell or tense did handle the task of automating installs. Edit: And starting from an base install you could easily bootstrap things further with my Migrations module.

You can also add fields, which let you manipulate the layout and not the content, but ProcessWire by itself does not concern itself with what your frontend does look like. You're fully on your own there (can be a good or bad thing depending on the situation).

A textareas field is a single field, but with lots of subfields. So yeah, you cannot put any of your other fields between those subfields. Kinda like it's with repeaters.

These are certainly nice projects, but I doubt a majority of users would need them, so they're probably a better fit for 3rd party modules than the core.

@ryan This might be a handy addition to the topic as well: https://gist.github.com/LostKobrakai/ddb11c64dcb0f1bf1c8eed4dd534a868 (prove-of-concept level) Chunked uploads would allow for file uploads beyond any php set limits even for files, which we obviously cannot shrink client side.

Yeah, the naming for those snippets do not match the style of the migrations generated by the module. They are rather meant to be copied over to existing migrations in your project. Edit: I've appended this to the README in the snippets repo.

Which ones?

There probably isn't. The pagefinder and Pages::getById and Pages::getFieldValue are the places where processwire does query the db for page data, with the first probably being the most elaborate piece. Converting your foreach into a single query is probably a bit difficult (selection and retrieval), but maybe 2 is enough for you. Use $pages->findIDs() and then your custom query with "WHERE id in (1000, 1001, …)"

$pf = $pages->getPageFinder(); $selector = new Selectors($selector); $query = $pf->find($selector, ['returnVerbose' => true, 'returnQuery' => true]); # Show sql $query->getQuery(); # Modify query $query->where($sql); # Run query $query->execute();

Maybe this is an option as well: https://processwireshop.pw

Not currently.

I'm not sure, I haven't used in in a while. But I haven't added the 3.0 flag for a purpose, because the module was build before the ability to assign additional permissions on a per template level was added. I'm not sure if the module does take those into account properly.

I'm not sure what exactly you mean. It should show the selectable items and filter them if you start typing.

id is a field of the page even though it's an InputfieldHidden one.

It's only downloadable in the ListerPro support forum.

ListerPro can do that with it's PageActions integration, but I'm not sure there's a installable pageaction module, which does publish pages, already.

From how I understand it this error should be in regards to what you supply via `$mail->to($recipient)` and not in regards to your module configuration.

Check the ajax upload call for the returned data. This will hopefully show what's the issue here.

Suppressing errors is a bad idea. Having "Integrity constraint violation" means something is trying to insert data with a key, which is already present in the database. Worst case scenario: You loose data because of it not being in a saveable state. This should be fixed and not be put aside (even it it's really a core issue and not one with your code).

The releases are only for (released) master versions, not for the intermediate dev versions.

Probably only via the commit history on github: https://github.com/processwire/processwire/commit/310ea9d2817279616469ac93533382443033bc13

Then it depends on directus how you keep things in sync. Either you trigger the sync in intervals or manually, where you simply recreate all pages, which have been updated in directus since the previous sync. Or directus does support some mechanism to trigger external things, if someone does update content.

Are you talking about html mails, where the images are blocked when viewing it? If so that's a setting of each individual email client / their users. That's nothing you can control on the senders side of the email.

I'd really suggest you to sort out why you need to have data in multiple places (especially edit them in multiple places). Keeping things in sync is a task, where so many things can go wrong, that it's often the better solution to keep things in one place. If you really need to sync stuff, one way sync (essentially caching) is the simple option, because you can just discard anything on the receiving end without worrying to overwrite any changes (especially useful if something did went wrong and you need to fix that). Two way sync is the hard part, especially as you need to handle things like potential downtime of both services, network issues, missed updates and so on.