LostKobrakai

Maybe use url segments for the whole url and just render the pages located elsewhere based in the infos supplied by the url.

If you want to stay compatible with the 2.x branch I'd simply develop on a 2.8 or even 2.7 installation.

There are various 3rd party modules around, which do allow for that kind of navigation. Please consult the modules directory and/or the modules subforum.

$pages->find() in general does take a selector, but as a convenience it does also check if the supplied selector is a single ID as integer (and seemingly as string as well).

Maybe here's a bit more information about it: https://processwire.com/docs/security/file-permissions/#securing-your-site-config.php-file Also the installer option for file/folder permissions wasn't present in earlier versions of processwire if I recall correctly(https://github.com/ryancramerdesign/ProcessWire/commit/f7c308566bebf0d39e8ec688d1e7795bf0c17f50) and it seems like it was only added to supply the values into the config.php and not to do any permission changes on installation. I think that's the confusion here: That modules/assets/templates weren't updated with the chmod setting supplied in the installer. Making the config.php readonly by default is not something i would advice, because it can firstly brick your installation and secondly it will prevent any runtime changes to this file and there are modules out there which do write to that file. So it would probably be nice to have the option, that the installer does also clean up any incorrect file/folder permission when installing – possibly even by default, because it'll show incorrect settings much earlier and not if the first file uploads do fail or something like that. Making the config.php readonly should still be considered a manual or at least a opt-in task.

ProcessWire 3 changed to using namespaces. In places where processwire can control loaded files (like wireRenderFile() or template files) it does have a file compiler to add the namespace on demand into the file. This is not possible with include() because there's no place to change the loaded file on demand, because it's all handled by php. So if your really need to use include() for the reason of sharing the variable scope you need to make sure to add the namespace manually in the included files.

foreach($posts->getValues() as $index => $post) { $is_large = $index % 6 == 1 || $index % 6 == 2 if($is_large) … else … }

The file compiler, which adds the ProcessWire namespace in 3.0 does not touch (and even can't touch) files, which are included via include()/require(), but only things like modules / templates and files included by processwire functions like wireIncludeFile / wireRenderFile.

I thinks it's a feature of the forum software, which belongs to the store. It's probably not possible to disable one, but not the other.

From my experience these shared hosters are exactly the ones without access to folders outside the webroot I don't want to totally invalidate the request for such a feature, it's nice to have options, but I can understand if there's not much priority for it.

ProcessWire does have an router, even though it does look vastly different to what you're talking about. It's routing requests by the page template to the corresponding template.php file. What you proposed does not correspond very well with that core routing strategy, because neither urls nor the http methods are the identifying factor here. It's the pages template and the existence in the page tree. If you're looking for a more traditional mvc routing layer, you can set an alternative template file for your templates (by hook or in the backend). Just point all of them to e.g. a router.php file and use whatever router package your like to route requests to wherever the action should be handled. And about the core routing of processwire. Always keep in mind that mvc frameworks do not have something like the page tree, which is why they need a router to work on the url of the request. ProcessWire does not need that with it's approach.

By now there aren't any known security issues with processwire core, so updating is purely needed for accessing new features. There's also no mailing list for security. The best is to follow the weekly blogposts by any of the available channels.

Repeaters do use templates to hold their selected fields. But these are normally marked as system templates and therefore hidden by default.

Take a look at MarkupSEO. It's doing that or you could copy the parts you need.

There's also this, if you don't want to create your own module:

For that kind of system I'd probably go with laravel spark.

In general I'd say build classes as independent as possible from processwire and to integrate it in PW just add a module as wrapper around your class, which does tie any processwire specifics (hook / module config / process interface / …) into what your class does on it's own.

That's not possible as you can only sort by values in a single column (in the db). You might try to use this: https://github.com/LostKobrakai/Paginator

FieldtypeTable is currently the only fieldtype supporting the pagination feature, but really the question is why you need all that pages to be in a pagetable. Can't they simply be children? Lister / ListerPro can already handle the need to display pages with additional tabular information.

Normally you simply copy all the files and the db over to their new location. Check the site/config.php to adjust the db credentials and you should be good to go. There's no need to install ProcessWire in the new location before that.

https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

The question is why is there a .htaccess in the first place and what's it's content. Probably the .htaccess is of cpanel or some other tool to manage the vhost. I'd imagine you could simply replace it, but without knowing the content we can't be 100% sure.

Another option would be: $page = $siteB->wire(new Page());

Basically every time you need to handle files bigger than say 100-200MB, but you don't want to / can't give php more memory. Also timeouts Given more free time I would've created a bit more fleshed out PR to the core, but it's currently not possible. The biggest thing to improve here would be some kind of cleanup, so chunks of unsuccessful uploads do not sit there forever. Keeping them for a short timeframe is nice, because it'll speed up second tries.

I'm using it for well over 1 and a half years in a production project and to be honest, what you'll do with it is way more likely to cause isses than the module by itself