LostKobrakai

You probably need to use different sessionNames for those sites (you can find the exact setting in wire/config.php) so it won't overwrite your session cookie, but I'm not 100% positive.

About the Inputfield names you're mostly correct, but it's ASM not Asn As php doesn't even allow you to extend of of multiple classes you would rather use those module's to render themselves as part of your module. The piece you'll need to add to allow both Inputfields to interact would be mostly JS work, but I'd say you need a good PHP understanding as well as InputfieldSelector is one of the most complex Inputfields we have in pw.

I can really recommend http://adamwathan.me/refactoring-to-collections/ if you're curious (has a free sample as well). Brought a lot of light into all those functions and their usefulness.

Since we are talking about the newish ModuleConfig class, which does not work for Robin: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ModuleConfig.php#L61-L68 This will return the default values. The older static method way really seems to need a forced manual save. But for anyone not implementing this, the module would also not receive any default values, therefore the workaround is kinda necessary anyways. And modules, which have "just been installed" are still already installed. I doubt we're talking about ___install() here, but even if we do, it should probably just work there, too, when using the ModuleClass.

$byColor = array_reduce($children->getArray(), function($carry, $child){ $carry[$child->color][] = $child; return $carry; }, array()); $toTextBlocks = array_map(function($color, $children){ $childrenPA = (new PageArray)->import($children); return "$color (" . $childrenPA->implode(", ", "title") . ")"; }, array_keys($byColor), $byColor); $line = implode(", ", $toTextBlocks);

I cannot find any request to getting those default config settings while installing the module. The problem I got from the topic is that getModuleConfigData() will return no value for as long as the module's settings weren't (manually) saved once after a successful install, which is imho bad handling of an edgecase. And since the module can pick up any defaults to supply them to $this->configValue calls, I cannot see why we would need anything new to make getModuleConfigData() return a useful result right from the start.

It doesn't. I mean is should just return the same data available through $this->myConfigValue, which in turn does (probably) only rely on the config inputfield names. Am I wrong on that? I mean the module does need to know about those values no matter if they are saved or defaults or anything else.

I sincerely think this should be an implementation detail and not something the user should worry about, especially if it's a different behavior than the old-school config method.

You could simple use $pageArray->slice($start, $limit);

$pageArray = $page->your_field; $total = $pageArray->count(); $limit = 20; $pageNum = $input->pageNum - 1; // make it zero based for calculation $start = $pageNum * $limit; $paginatablePageArray = $pageArray->setStart($start)->setLimit($limit)->setTotal($total); This way you'll get a PageArray, which will work like any $pages->find() one in terms of pagination.

The question is to how many of those "features" you need this to scale. Are we talking about 10s, 100s or 1000s of them? Just implementing pagination for a pagearray is quite easy, as long as you've no problem laoding the whole pagearray into memory each time.

Nope. At least you cannot prevent the field from loading all pages in the first place. You could still choose to show only parts of them, by manually setting setLimit() setTotal() setStart() on the pagearray.

It's a class on the button. Just remove it to prevent the cloning.

Until Ryan can come up with something more elaborate I'll just share a snippet of him here. In template files you'll just need the part beginning with $config2 …. <?php namespace ProcessWire; // This file is named /nstest/multi-instance.php // and it exists in the first test installation // loaded at: http://localhost:8888/nstest/multi-instance.php echo "<pre>"; include("./wire/core/ProcessWire.php"); // Test first instance: /nstest/ $config = ProcessWire::buildConfig(__DIR__); $wire = new ProcessWire($config); $items = $wire->pages->find("id>0, include=all"); foreach($items as $item) { echo "$item->url\n"; } echo "\n---------------------\n"; // Test second instance /xyz/ $config2 = ProcessWire::buildConfig(realpath("../xyz/"), '/xyz/'); // LostKobrakai: Not sure, but I need this next line for it to work $config2->paths->modules = $config->paths->modules; $wire2 = new ProcessWire($config2); $items = $wire2->pages->find("id>0, include=all"); foreach($items as $item) { echo "$item->url\n"; } echo "\n---------------------\n"; // Test first instance again foreach($wire->pages->find("body*=about") as $item) { echo "$item->url\n"; } A working example of that is running here, where the images are pulled from my photography page: https://www.kobrakai.de/ Edit: Now it's also visible (missed to uncache the page).

$page = $event->object->getPage();

The strange thing is, that PageArray::get() is internally just syntactic sugar for $pa->find()->first(). So does this work? $page->siblings->find("name=some-name, include=hidden")->first(); Maybe the returned PageArray of siblings is already excluding your hidden page.

Can you post your exact used showIf selectors here and how these fields are named? From a plain explanation it's hard to guess where the issue comes from.

You're not hooking anything related to those buttons. This one would even execute if anything on the frontend would save a blog-entry. I'd suggest taking a look at the hooks provided by ProcessPageEdit.

ProcessPageType is probably the base for ProcessUsers. You can read a bit more about pagetypes here: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/

Thanks for the tip with the on demand field join. I'm always a bit hesitant to use autojoin, but I'll certainly give this a try on all my reporting / listings pages.

The image field is already using the file-api (if supported). But I'd imagine that the reason for pages like wetransfer to use flash instead of native technology.

This might be useful to anyone trying to convert a (single) existing file field to a secure one, while maintaining integrity of other file fields on the same pages. Put a file with this content in pw's root directory and run it from the terminal: <?php include "index.php"; // allow for: $ php filename.php fieldName $fieldName = !empty($argv[1]) ? $argv[1] : 'file'; $field = $fields->get($fieldName); $usedInTemplates = $field->getTemplates(); $fp = fopen('files.txt', 'w'); // the use() statement allows for both pre and post pw 3.0 usage without change/compiler $eachPageUncache = function($selector, callable $callback) use ($pages) { $num = 0; $id = 0; while (true) { $p = $pages->get("{$selector}, id>$id"); $id = $p->id; if(!$id) break; $callback($p); $pages->uncacheAll($p); $num++; } return $num; }; try { // Alternatively use findMany and a foreach on PW 3.0.19+ $eachPageUncache("template=$usedInTemplates, include=all, check_access=0", function($page) use($fp, $fieldName, $config) { $files = $page->getUnformatted($fieldName); foreach ($files as $file) { $path = str_replace($config->paths->files, '', $file->pathname); fwrite($fp, $path . PHP_EOL); } }); } finally { // PHP 5.5+ fclose($fp); } Then you can use the created files.txt to copy files to their new location (add --remove-source-files to also remove the source files). rsync -v \ --files-from=PW_ROOT_PATH/files.txt \ PW_ROOT_PATH/site/assets/files NEW_LOCATION_PATH Switch the file field to be a secure file field and all files should still work.

If the "texts" would be a options/page field then you can sort them in the page tree / field setup accordingly and willyc's last example would still work.

Take that step right now and simply include "require __DIR__ . '/../vendor/autoload.php';" in your config.php or init.php. Until composer pw modules will become more often this is essentially what pw 3.0 does in terms of composer support.

parent=page.pagefield should work. At least in the default page editor everything page.x should work.