MarkE

Thanks @matjazp. The issue is well-documented there. In my case, it ocurred after a database load and a modules refresh (not a PW update). I suspect the issue was caused by loading a database from a later PW version (3.0.229). I removed the rows from the modules table and all seemed OK after that. I then updated to 3.0.235 and the rows are back in the table, but no errors are shown. So it appears to not be a bug as such (or at least is fixed) but will probably still happen if someone downgrades or loads a database to an older PW version.

.. or even taking advantage of newer html5 developments. For example, <details><summary>. I guess the fundamental issue is that this is always a moving target, so it makes sense to not try and track the latest fashion, but to move when it is clear that the way forward is established and generally accepted.

Do you have dynamic loading on?

I kept getting these errors on my modules page on one site I have no such modules listed, but inspection via Adminer shows that they have entries in the modules database. Each entry has data listing a number of modules, such as (for .ModulesVerbose.info). 178 summary Tracy debugger from Nette with many PW specific custom tools. author Adrian Jones href https://processwire.com/talk/forum/58-tracy-debugger/ versionStr 4.23.33 I assumed that the database got corrupted somehow (but how?), so I deleted the entries. Everything seems to be OK.... Any ideas what might have caused this? Anyway, thanks @adrianfor Adminer - always useful in extremis.

Hmm. Thanks @Robin S. I had already tried something similar with no success. I tried your hook, but it doesn't seem to get triggered in the particular circumstances I described (i.e. when the field is not added to the templates, just included as a column). UPDATE: However, $wire->addHookBefore('FieldtypeRuntimeOnly::markupValue', function(HookEvent $event) seems to do the trick In fact, since I was using a forked hacked version of your module anyway, it was simpler to add $inputfield = $field->getInputfield($page); $inputfield->renderReady(); in markupValue() - just before return $this->renderMarkup($page, $field); ?

OK - a really simple solution if you only concerned about one Page Table Field on the relevant pages. In my case, this is in the context of a module, where the name of the Page Table field is 'motif_block_table'. In the module's ready(): $this->addHookAfter('Pages::moved', $this, 'afterPagesMoved'); then: protected function afterPagesMoved(HookEvent $event) { $page = $event->arguments(0); $oldParent = $page->parentPrevious; $newParent = $page->parent; if($oldParent->id == $newParent->id) return; if($oldParent->hasField('motif_block_table')) { $oldParent->motif_block_table->remove($page); $oldParent->setAndSave('motif_block_table', $oldParent->motif_block_table); } if($newParent->hasField('motif_block_table')) { $newParent->motif_block_table->add($page); $newParent->setAndSave('motif_block_table', $newParent->motif_block_table); } } So now I have only one operation - namely to move the page in the page tree - and both fields get reset accordingly (although it may be necessary to re-sort the receiving page table as the new child will be added at the end, regardless of where you drag it in the tree). NB this will not work unless your page naming ensures unique names, as there is a risk that the new parent already has a page with the same name as the one you are moving and the move will be forbidden until you rename one of them. This could easily be generalised to operate outside of a module. It could also be adapted to refer to an unspecific Page Table field, provided there is only one. If there is more than one Page Table field and you want to track moves, it gets a bit trickier: finding the field to remove the page from is easy enough; then you either need to do something clever in js to select which field it is added to, or else (probably simpler) just go to the page and add the new child to the relevant field.

It would be nice to have a simple-to-use solution for this - like the copy/clone/paste options now available for repeaters. My current method is: In the page tree (using the 'children' tab is best, assuming there is a common parent), copy the page Delete (trash) the old page Move the copied page to the new location, edit the title and any other required fields and publish it. In the Page Table listing for the new parent, add the new child It would be super to halve the number of steps: In the old Page Table list, cut/copy the page In the new Page Table list, paste the page

Hi @Robin S. The module is really neat and I've forked and hacked it a couple of times to simplify it for use in my own modules (with accreditation!). I came across an interesting feature of PW recently regarding Page Table fields. If I create a Runtime field and include it as a column in a PageTable field, I do not need to include it in any of the templates managed by the Page Table field (assuming it is only needed to display in the Page Table field). This is a really handy way of providing useful information in the Page Table listing and saves a bit of effort, especially if there are lots of templates. However, the js and css is not then automatically picked up. I fixed this by moving the code in InputfieldRuntimeOnly::renderReady() to FieldtypeRuntimeOnly::renderMarkup() and also moving getPath() and getUrl(). Everything seems to work like this in both the normal (field in template) and novel use. I wondered whether there was a particular reason for putting it in renderReady(), as it would seem more usable in renderMarkup()?

Hmm. I did that but could not reliably replicate the problem. The main check seems to be a js alert "Module requirements are not fulfilled so installing may cause problems. Are you sure you want to install?". This was not always appearing in the set-up that prompted my original post, but it did sometimes and I can't see what caused it to be omitted. Nevertheless, the user can override the alert and install anyway. Often, this is not a problem as the required module can be installed subsequently. However, where the required module is really required for a successful installation (such that reversion to a backup may be necessary if the installation is not complete) then I think it is wise to include the additional check that I described above. This would particularly be the case if, for example, RockMigrations or ProcessDbMigrate was required to install the necessary objects for the module to work.

I can sort-of achieve this by explicitly checking in the install() method and throwing an exception in the following manner: if(!wire()->modules->isInstalled('RequiredModule')) { throw new WireException(__("Unable to install MyModule without first installing RequiredModule")); return; } However, that seems rather cumbersome and I would have thought it should be unneccesary when the {module}.info.php already declares the requirements. Update: I have tried to investigate where the requirements are checked and dealt with, but it's very confusing. ModulesLoader.php (463) gives an error message, but just when listing, not as part of the installation. ModulesInstaller install() method seems to be the main place - line 96: $error = $this->_('Unable to install required module') . " - $requiresModule. "; but that doesn't always seem to operate for reasons I have not yet been able to ascertain. Am I alone with this problem??

Does anyone know how I can insertt a font awesome icon into notes text for a field? For example, I currently have this in the definition of a config inputfield for a module: $f->notes = $this->_("Needs to be a page with Category template (right-caret icon). Create one if it doesn't already exist."); I would like to show the actual icon rather than just describe it

This may be a simple question from a 'simple' person, so I hope there is a simple answer! I have built a module that will not work without certain other software and have a 'requires' statement in the {module}.info.php file like 'requires' => ['ProcessWire>=3.0.200', 'RockFrontend', 'ProcessDbMigrate>=1.0.19'], This all appears to be present and recognized when installing the module. However, the module is shown as being installed even if the requirements are not met but, of course, it is not installed correctly as it needs (for instance) ProcessDbMigrate to install it fully. How do I actually stop the install from happening if the requirements are not met?

... well, more like the indented (conditional) dropdown in the setup menu, otherwise you still have lots of scrolling. TextTags also saves lots of scrolling, as @bernhardsays. Needs a bit more though before making a feature request. BTW @monollonom, I think your module should be in the core! Maybe the best quick solution is to install SelectizeAll by @Robin S

Great module @monollonom. Really pleased to have discovered it recently. Now if only we could do the same for the fields dropdown on the template edit page....

Looks spot on to me!

Thanks @monollonom. That's really useful. I'm in 2 minds about the best way to handle system fields etc. Your module groups any system fields together (even if they are also tagged). That may be the best way, but it does mean that it loses the benefit of tagging any custom system fields.

I know this is a rather old post, but did it go anywhere? Also, could it be possible to exclude system fields/templates from the dropdown (via an option in the UIkit config)?

Looks ok on my iPad

Nope ?"This private-user-images.githubusercontent.com page can’t be found" But it's fine in GitHub and the modules library ?

Looks good @Robin S, but images seem to be missing in the above post.

Tags are an option too @heldercervantes - use Text Tags inputfield with Page Reference field type and select "allow new pages to be created from field", but I haven't used that with a 'section' hierarchy such as that suggested by @BitPoet. EDIT: BTW, the CustomDependSelects module was specifically designed to operate inside repeaters. Whether you use that or the grouping method is a question of how many pages there are and your personal preference.

I would say page selects are the way to go. You could try my module https://github.com/MetaTunes/CustomDependSelects

Not sure if this is of any help, @bernhard, but I had a similar sort of need in my home-built pagebuilder module. The following code is called from the module init() protected function allowableLayouts($allowedLayoutFieldName) { // Create the options for motif_allowable_children/sublayouts being all the pro-forma layouts $layouts = $this->pages->find("template=MotifLayout"); //bd($layouts, '$layouts'); if($layouts && $layouts->count() > 0) {// Prevent deletion of options if pages not yet loaded $options = new selectableOptionArray(); $i = 1; foreach($layouts as $layout) { $option = new SelectableOption(); $option->set('id', $layout->id); // use page id as this should not change as components are added, changed and deleted $option->set('sort', $i); // this assigns the correct value but seems to have no effect on the display order $option->set('title', $layout->title); $option->set('value', $layout->path); //bd($option, 'allowable child'); $options->add($option); $i++; } $allowedLayoutField = $this->fields->get($allowedLayoutFieldName); if($allowedLayoutField && $allowedLayoutField->id > 0) { //bd($options, 'Allowable options for ' . $layoutField); // ToDo - Make this conditional on there being a change (better efficiency) after being satisfied that it works OK $allowedLayoutField->type->setOptions($allowedLayoutField, $options); } } } The above is presented "as-is" but, if it is relevant, I'm sure you can adapt as required.

Now in the modules library at https://processwire.com/modules/process-db-migrate/.

Solved @bernhard! Table pages_paths was missing all ids < 1017. Rebuilt as follows: $pagePaths = $modules->get("PagePaths"); $int = $pagePaths->rebuild();