Robin S

The view permission controls viewing on the front-end, it doesn't relate to pages being listed in Page List. For more advanced control over page permissions try hooking after the following Page methods, returning true/false as needed. $page->listable() is the one related to which pages appear in Page List. $page->listable() bool Returns true if the page is listable by the current user, false if not. Can also be used as property: $page->listable $page->moveable() bool Returns true if the current user can move this page. Optionally specify the new parent to check if the page is moveable to that parent. Can also be used as property: $page->moveable $page->publishable() bool Returns true if the page is publishable by the current user, false if not. Can also be used as property: $page->publishable $page->restorable() bool Returns true if page is in the trash and is capable of being restored to its original location. @since 3.0.107 $page->sortable() bool Returns true if the current user can change the sort order of the current page (within the same parent). Can also be used as property: $page->sortable $page->trashable() bool Returns true if the page is trashable by the current user, false if not. Can also be used as property: $page->trashable $page->viewable() bool Returns true if the page (and optionally field) is viewable by the current user, false if not. Can also be used as property: $page->viewable An example of a Page::listable hook - note that such hooks do not restrict the superuser role: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; if($this->wire()->user->hasRole('editor') && $page->template == 'basic_page') $event->return = false; });

Enable debug mode to get more informative error messages. Open file /site/config.php via FTP or hosting file manager and edit the line below to set debug mode true, or add the line if none exists. $config->debug = true; It's possible if the original superuser was deleted, but that's not a common scenario. You could try adding a new superuser account by adding and loading the following "add_user.php" file in the site root. <?php require './index.php'; $u = new User(); $u->name = 'new_user'; $u->pass = '123456'; $u->addRole('superuser'); $u->save(); Edit: by the way, you can also find the names and ids of the existing users by looking in the pages table of the database. In phpMyAdmin or similar, sort the table by the templates_id column, and look at the names and ids of rows where templates_id is 3 (3 is the id of the user template).

Alternatively you can hook after ProcessPageSearch::findReady to make it a bit more specific to autocomplete:

Try... 1. Create file "reset.php" containing the following (beware of non-printable characters creeping in - to be sure you could type it out rather than copy/pasting): <?php require './index.php'; // Bootstrap ProcessWire $admin = $users->get(41); // Get the default superuser by ID $admin->of(false); // Set output formatting off $admin->name = 'yourNewUserName'; // Set the name $admin->pass = 'yo123456'; // Set the password $admin->save(); // Save the user 2. Upload reset.php to the site root (where the ProcessWire index.php file is). 3. Load the file in your browser: https://guidetodrawing.com/reset.php 4. Login with the user details at: https://guidetodrawing.com/admin/ 5. Delete reset.php

Yeah, I think you're right that this would be better.

That does make some sense to me, because httpRoot is not a setting that is defined anywhere but more like "given the way you are accessing this website right now, this is the root URL". Imagine a site that had several domains that are valid to access the site at, or a site where both HTTP and HTTPS protocols are allowed without redirect (lets disregard the SEO implications of all of this). The httpRoot would be expected to change depending on the domain/protocol you are accessing the site at. If you are using the CLI then PW doesn't have a protocol or domain to refer to so it just gives you the first allowed httpHost (rather than giving you nothing which would arguably be worse). This is how I imagine the thinking goes - I haven't looked at the code.

Love this module, but how come the edit icon that is added to the inputfield is fa-search? I reckon fa-pencil-square-o would be more suitable for an edit icon.

I don't think this behaviour is related to the pattern that is used. When a field is set to "required" or with some validation rule then PW gives feedback to the user when the field is not submitted in the correct state but it saves the form regardless. Client-side validation prevents form submission but this is a browser feature not a PW feature. The PW behaviour is deliberate and @ryan has explained the rationale behind it somewhere - I can't find it at the moment but maybe someone else will chime in with a link. Perhaps Ryan would be open to having an option to restore the previous value in case of failed validation, seeing as that option exists at the template level for required fields. You could make a request at GitHub. Also see Soma's hook solution:

Perhaps you have auto-prepended and/or auto-appended template files in your /site/config.php, in which case you would want to use the $options array to override those when rendering the page, e.g. foreach ($pages->find("template=article") as $article) { $content .= $article->render('teaser.php', ['appendFile' => null]); }

Hi @ryan, could you please add some more detailed documentation for the $page->render() method to the API docs? Currently the details are quite minimal (the method doesn't have it's own page but just a short entry on the $page documentation) and doesn't cover all the options that you describe in this post: I guess the docs for $page->render() need to somehow pull in the PhpDoc comments from PageRender::renderPage().

Welcome to the PW forums @Anders! There are many different ways you could do this and at the end of the day it comes down to personal preference. Myself, if this was a one-off listing of teasers that wasn't to be used on other templates I would tend to build the markup directly in the template file and not render any other files. And if it was a listing that was to be used in several template files I would tend to render a file that looped over multiple pages and I would pass those pages to the rendered file. I prefer to output markup directly and make use of the Markup Regions feature, but to keep with your case of populating a $content variable it would be something like this: $content .= $files->render('teasers', ['items' => $pages->find("template=article")]); BTW, the wireRenderFile() function is sort of obsolete as far as I can see because it is just an alias for $files->render(). But if you wanted to render a page with something similar to your example... ...then you could look at the (largely undocumented) $page->render() method. The best resource that I know of for this method is Ryan's post here: Also you can read the comments for PageRender::renderPage() in /wire/modules/PageRender.module (which is what $page->render() calls behind the scenes). So you could do something like: foreach ($pages->find("template=article") as $article) { $content .= $article->render('teaser.php'); }

I did some testing to see what is needed to get required-if conditions working within repeaters and opened a request here: https://github.com/processwire/processwire-requests/issues/262

I just tested and couldn't find any problem with required if conditions inside a repeater - like you said, they seem to work fine. And I tried it some while ago and couldn't find a problem then either: So maybe there are some specific types of required if conditions that don't work, or maybe it was a limitation that was later fixed. Do you want to file a GitHub issue so Ryan can take a look and either clarify the types of condition that don't work or else remove the notice? Edit: scratch all that - the required if conditions don't work as expected inside a repeater. At first it seems that they do work, because when you fulfill the required if condition the asterisk appears and the field is indeed required. But the problem is that field is always required, so even if you don't fulfill the required if condition and the asterisk is removed the field is still required.

There is a notice Regarding "Page List" input types... But the "specify only the parent" part of that is contradicted by the requirements for the core "allow new pages to be created from the field" option, so if you want that you would need to specify a template also. The template only relates to the new page that is added - it doesn't restrict the selectable pages for a Page List input type. If you're committed to the Page List input type and want to try workarounds for restricting the types of pages that can be selected you could look at hiding the "Select" button according to the class of page item in the inputfield. See the thread below for a different context but the same general idea:

If you mean you want to have different toolbars for different matrix types that use the same CKEditor field then changing field settings in template context is not going to be a solution because all matrix types within a Repeater Matrix field use the same template. And some hook that checks the matrix type is not going to be a solution either because there is only a single CKEditor configuration per CKEditor field that is sent to the ProcessWire.config JS object. So all instances of a CKEditor field on a page get the same config. I think the only way to have different CKEditor configs for different matrix types is to use a different CKEditor field for each matrix type that needs a custom toolbar. If you want to use those CKEditor fields in different templates besides the Repeater Matrix template then you can use template context for overrides.

Nice one @Sebi2020! Maybe you could look at enhancing the module by allowing the configuration of some Tagify options within the field settings. In particular I'm thinking it would be good to be able to set the "whitelist" and "maxTags" options.

I've added support for CKEditor within a Table field in v0.1.10.

Your cache function doesn't return JSON though, but rather a PageArray with the full user objects. I suggest only returning the JSON data you need to see if that makes a difference. That's correct. A solution is to use $pages->findMany() with the user template. $members = $cache->get('members', '+10 minutes', function($pages) { $member_pages = $pages->findMany('template=user, roles=member, sort=lastname, limit=3000, check_access=0'); return json_encode($member_pages->explode(['name', 'email'])); // Whatever fields/properties you need from the member pages });

You can set the default sort via a hook in /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /* @var ProcessPageLister $lister */ $lister = $event->object; // Only for Users lister if($lister->parent->id !== 29) return; // Set the sort to whatever $lister->defaultSort = 'email'; }); Note that the user can change the sort within the lister, and this will persist for the current session. So to get back to the default sort you are setting in the hook the user would need to reset the lister: Or if you want the default sort to apply every time the Users lister is visited (but still allow the user to change the sort while they are using the lister) then you could do this: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /* @var ProcessPageLister $lister */ $lister = $event->object; // Only for Users lister if($lister->parent->id !== 29) return; // Reset the sort when the lister is first loaded if(!$event->config->ajax) $lister->sessionSet('sort', ''); // Set the sort to whatever $lister->defaultSort = 'email'; });

JSON in the description field is detected if the first character is { and the last character is }, or if the first character is [ and the last character is ]. See here. So one workaround could be to prefix the JSON with some character... *{"json": "here"} ...and then trim the first character before the module decodes the JSON.

Thanks for the updates @ryan! Going forward, what do you think should be done about the sanitizer methods included in the PhpDoc of WireInputData? These sanitizer methods are also the basis for what gets an entry in the API documentation for WireInputData. As noted in this request the sanitizer methods included in the WireInputData PhpDoc were already out of date (i.e. incomplete). The new $santitizer methods added in 3.0.125 are also not included there. Do you think the PhpDoc of WireInputData should just aim to keep pace with new $sanitizer methods as they are added? Or now that multiple methods can be chained together... // access sanitizer on $input as method $q = $input->get->text50_entities('q'); ...in a way that couldn't be handled as lines in the PhpDoc, perhaps it would be better to drop the list of sanitizer methods and instead include some general note about how $sanitizer methods (with a link to the $sanitizer documentation) can be used/chained with $input?

@szabesz, there's nothing broken in the "official version" of FieldtypeDecimal that's in the modules directory. I use it in nearly every project without problems. Arjen's fork adds a feature for distinguishing empty and zero values in a selector that a person may or may not need (personally I've never needed it so far).

There are limitations to the number of significant figures that can be stored by the FLOAT column type in the database. There are also precision limitations to how floats are handled in PHP. These are fundamental limitations and PW cannot do anything about them. However it would be good if the PW admin warned the developer about them so people aren't caught out - there is a request for this but it hasn't been actioned yet: https://github.com/processwire/processwire-requests/issues/173 Best to use the Decimal fieldtype in cases where the limitations of the Float fieldtype are a problem.

I had to do something like this recently. The "include" clause in the selector applies to the whole selector - you cannot have an include clause apply only to one OR-group. So the solution is to use include=hidden outside of the OR-groups, then exclude hidden pages within the OR-groups where you don't want the include=hidden to apply. So the selector for your example above would be: $results = $pages->find("(template=x|y|z, status!=hidden), (template=a), title|body~=$searchquery, include=hidden");

If you want to load your CSS/JS assets last in the <head> then see this approach too: