LostKobrakai

A PageArray can only hold one instance of each page, so yeah it does, but it's not really explicit that way (and won't work as expected with my paginator)

You'd should differentiate that in your selectors. There's nothing happening automatically.

Create a module of the "Process" type here: http://modules.pw/ In the ___execute() function you can do your work and after that use this to redirect wherever you need: $this->session->redirect($url, false); I'm just not sure how exactly you could get the previous location's url.

You can just use two different find calls and just join them: $top = $pages->find(…); $bottom = $pages->find(…); $all = $top->import($bottom); And if you need pagination use this: https://github.com/LostKobrakai/Paginator

Feels nice and cosy. I really like it.

The use statement does nothing in you snippet. If you want to use "use", then like this: <?php namespace ProcessWire; use DateTime; $date = new DateTime();

That's exactly the reason why I feel migrating the repo would be the better choice to starting from scratch. The same is with the git history. The processwire/processwire doesn't have any.

You can still disable the html minification.

I'm not sure renderNav() does work with a native array, but $pages->find('something') will return a PageArray object anyways.

Both things are not really php specific, but more common oop concepts. They're certainly not pw specific. http://php.net/manual/en/language.oop5.typehinting.php http://php.net/manual/en/internals2.opcodes.instanceof.php

imagesLoaded is a separate package: http://imagesloaded.desandro.com/

Use a DefaultMigration and add / remove repeater like anywhere else: https://processwire.com/api/fieldtypes/repeaters/ (Using the API to add or remove repeater items) Same thing with images:

Are you using namespaces? If so then it would need to be (\Exception $e)

$fieldgroup = $template->fieldgroup; $f = $fieldgroup->getField($fieldName, true); // Do stuff $fields->saveFieldgroupContext($f, $fieldgroup);

"allowRelative" does state to me that relative urls are additionally allowed to the default behavior. So if it's not relative it's trying to cast the string to an absolute url. Your needed behavior would rather need to be named "onlyRelative" or alike. Maybe even a different sanitizer.

They do all work.

It can be as short as this: <?php /* add to a page object with parent path and new pages template name */ $newPage = $pages->add('tmp_api_test_post', '/api-test-start/', $randTitle, array( 'title' => $sanitizer->text($randTitle), 'api_test_hash' => $randHash ))->setOutputFormatting(true); The longform function to enable output formatting does return the page instead of the current of of status, so you can simply append it, whereas ->of() would make your $newPage variable useless.

Even Excel for Mac and Excel on Windows do use different encodings.

You should probably take a look at this one, which does the same, but far less verbose: https://processwire.com/api/ref/pages/add/

Which version are we talking about? I'd imagine the validation part is only to ensure, that things added by processwire do result a correct url.

Sanitization is the act of trying to return a value in the expeted format in as many situations as possible. Everything else is rather validation and would therefore be on your own to do.

I see various reasons for that: The forms API was always only a tool for the admin backend (and a bit for form builder), and therefore never really meant to be greatly restyleable, but with the recent addition of styling possibilities via form builder this did even improve a great deal. In the backend forms are essentially a (more or less long) list of inputfields. The markup does need to fulfill all the need the backend does throw at it, meaning it does not only need to hold various types of single / multi-value inputs, but also the title, description notes and some kind of collapsing method. That's just more than the run of the mill css framework markup does offer.

https://processwire.com/api/ref/pagefile/description/

Only the name for the default language does need to stay. The title can be freely changed to the title of the language which actually is your default.

Vue 2.0 does have server side rendering, but it's only for node not php. One could however use processwire only as data provider and node only for rendering. One could probably implement the ssr part in php as well, but it would be a lot of duplication work. And everything, which does not share templates directly is just not maintainable for anything bigger. I'm personally using vue only for html/interface bits, which are useless without js anyways, therefore there's no need to generate it's html on the server.