Robin S

Ahh, the config inputfield was inheriting those settings from the field, which is unwanted. Should be fixed now in v0.1.1. Thanks for bringing it to my attention.

I don't understand. It's not mandatory to set an initial value setting for a field, and if you have chosen to set an initial value it's not mandatory to keep it for any given page in Page Edit - you can clear the initial value.

@MarkE, not sure I understand the issue but I've removed the InputfieldPage::isValidPage() check in v0.3.7 because it seems unnecessary seeing as FieldtypePage will itself do this validation before it saves a value.

@MarkE, I reported the issue here: https://github.com/processwire/processwire-issues/issues/1904

Hmmm, I'm not keen to add that. A NullPage has an ID of 0, and it shouldn't be possible to have a Page object that lacks an ID. Therefore when a PageArray is cast to a string it should never be possible to get something that looks like "|20896|20897" where there is clearly a missing ID for the first item. If your code is somehow producing a Page object that lacks an ID then I think that's a core issue that should be reported, because in general it ought to be safe to use a PageArray in a selector without needing to check for missing IDs. But for Ryan to fix I expect you'll need to create a reproducible test case.

Thanks @MarkE, have applied the fix in v0.3.6.

Just to add to this: the Move action is only removed if there is a "Children are sorted by" setting on the parent template or the parent page. Because even if there are no other allowed parents, the Move action is present to allow sorting within the existing parent so long as no fixed sorting is set.

@adrian, nice!

OMG, yes. That's one of the things I override in my custom mods as the default is crazy big. Off topic, but I really think AdminThemeUikit could be improved if some of the Uikit defaults were overridden in the module. Because the default sizing and white space is just too much for an admin panel where the focus should be on functionality and efficiency. And if a few basic things like that were done then users might not feel the need to make custom themes which from past experience I think are the wrong way to go (maintenance nightmare). I did turn them off, mainly because of the screen efficiency thing again. Ideally there would be some way to have them appear without increasing the overall size of the field (maybe on hover or some other way of activating them on demand), but I can see how that would be tricky. Maybe the core should provide for a flyout menu per inputfield that other modules could add links/icons to? Just thinking out loud.

Fantastic, thanks! I think I'll use standalone mode because its more efficient in screen real estate and I always open Adminer in a new tab, but it's really nifty how you solved the query string issue for the iframe option.

It looks like there is a clash with the Wappalyzer Chrome extension. When I log event.data it fires many times with results like this: Hopefully there's a way to allow it to coexist with Wappalyzer because I find it a useful extension. I forgot to mention before that I also see this notice: Thanks.

Hi @adrian, those features sound cool, thanks! But after upgrading one of my test sites to the latest version I first got this when visiting Setup > Adminer: Then after a modules refresh I got a better looking result but the query string doesn't seem to be doing what it's supposed to:

I'd be happy with either of those - would be good to have something to make it a bit easier to effectively go back to the previous behaviour because I have quite a few sites that I'll be updating Tracy on.

Thanks, that works well 👍

Hi @adrian, Thanks for the recent Tracy updates! Once change I noticed is that Setup > Adminer now displays within an iframe in the PW admin. There might be some advantages to this but it means that you lose your location when you refresh the page because the query string isn't in the browser address bar any more. I often want to navigate to a particular table or row and then refresh the page to observe the changes after some API operation. So could there be an option to have Setup > Adminer load without an iframe (i.e. how it was in previous Tracy versions)?

The custom fields rely on a template so, for example, when you export/import a field named "images_custom" you also need to export/import the template named "field-images_custom".

Similar to my suggestion to your earlier question, I think you should give your roles the necessary permissions to edit/create/add children for all the templates they will be working with. If you don't do this you're going to be fighting against what PW thinks that users with those roles are allowed to do and it will be more difficult to achieve what you want. Once those roles have the generic permissions to do what they need to do then focus on selectively taking away those permissions in your custom hooks according to your test on $user, $page, $parent, etc. Also, I've never understood the advantage to not explicitly setting access to every template. "Inheriting" access just seems like a recipe for confusion and accidental oversight. It only takes a short while to set the template access you want roles to have, and even less time if you use the Template Access module. Below is some code with demo logic for determining the allowed templates. You would replace that with your own logic which I expect would use some combination of $parent and $user. $wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function(HookEvent $event) { $allowed = $event->return; $parent_id = (int) $event->wire()->input->get('parent_id'); if(!$parent_id) return; $parent = $event->wire()->pages->get($parent_id); // Your custom logic here to remove any disallowed templates if($parent->template == 'basic_page' && $event->wire()->user->name === 'test-editor') { $allowed_template_ids = [29, 78]; foreach($allowed as $template_id => $template) { if(!in_array($template_id, $allowed_template_ids)) { unset($allowed[$template_id]); } } $event->return = $allowed; } });

The "1 to 10 of 20" part is something you get from PaginatedArray::getPaginationString() rather than from MarkupPagerNav. So if your paginated results are in a variable named $results you would do something like this: <p>Showing <?= $results->getPaginationString() ?> results</p> And the Previous/Next navigation: unfortunately MarkupPagerNav doesn't provide a direct solution for this. There's an open request for it: https://github.com/processwire/processwire-requests/issues/248 So for now you have to hide the numbered links with CSS (the easy option) or code your own Previous/Next links.

@sz-ligatur, the dependent selects feature only works if both inputfields are one of the following: Select, Select Multiple or AsmSelect @ryan, it would be great to have this feature documented somewhere.

Verify Links Periodically verifies that external links are working and not leading to an error page. How it works The module identifies links on a page when the page is saved and stores the URLs in a database table. For the purposes of this module a "link" is an external URL in any of the following... FieldtypeURL fields, and fields whose Fieldtype extends it (e.g. ProFields Verified URL) URL columns in a ProFields Table field URL subfields in a ProFields Combo field URL subfields in a ProFields Multiplier field ...and external href attributes from <a> tags in any of the following... Textarea fields where the "Content Type" is "Markup/HTML" (e.g. CKEditor and TinyMCE fields) CKEditor and TinyMCE columns in a ProFields Table field CKEditor and TinyMCE subfields in a ProFields Combo field The link URLs stored in the database table are then checked in batches via LazyCron and the response code for each URL is recorded. Configuration On the module config screen you can define settings that determine the link verification rate. You can choose the frequency that the LazyCron task will execute and the number of links that are verified with each LazyCron execution. The description line in this section informs you approximately how often all links in the site will be verified based on the number of links currently detected and the settings you have chosen. The module verifies links using curl_multi_exec which is pretty fast in most cases so if your site has a lot of links you can experiment with increasing the number of links to verify during each LazyCron execution. You can also set the timeout for each link verification and customise the list of user agents if needed. Usage Visit Setup > Verify Links to view a paginated table showing the status of the links that have been identified in your site. The table rows are colour-coded according to the response code: Potentially problematic response = red background Redirect response = orange background OK response = green background Link has not yet been checked = white background Where you see a 403 response code it's recommended to manually verify the link by clicking the URL to see if the page loads or not before treating it as a broken link. That's because some servers have anti-scraping firewalls that issue a 403 Forbidden response to requests from IP ranges that correspond to datacentres rather than to individual ISP customers and this will cause a "false positive" as a broken link. For each link the "Page" column contains a link to edit the page and the "View" column contains a link to view the page on the front-end. You can use the "Column visibility" dropdown to include a "Redirect" column in the table, which shows the redirect URL where this is available. For those who can't wait The module identifies links as pages are saved and verifies links on a LazyCron schedule. If you've installed the module on an existing site and you don't want to wait for this process to happen organically you can use the ProcessWire API to save pages and verify links en masse. // Save all non-admin, non-trashed pages in the site // If your site has a very large number of pages you may need to split this into batches $items = $pages->find("has_parent!=2|7, template!=admin, include=all"); foreach($items as $item) { $item->of(false); $item->save(); } // Verify the given number of links from those that VerifyLinks has identified // Execute this repeatedly until there are no more white rows in the Verify Links table // You can try increasing $number_of_links if you like $vl = $modules->get('VerifyLinks'); $number_of_links = 20; $vl->verifyLinks($number_of_links); Advanced There are hookable methods but most users won't need to bother with these: VerifyLinks::allowForField($field, $page) - Allow link URLs to be extracted from this field on this page? VerifyLinks::isValidLink($url) - Is this a valid link URL to be saved by this module? VerifyLinks::extractHtmlLinks($html) - Extract an array of external link URLs from the supplied HTML string https://github.com/Toutouwai/VerifyLinks https://processwire.com/modules/verify-links/

When searching a datetime field the PW PageFinder can use any string that the PHP strtotime() function understands. So the problem you're describing only relates to limitations on the input where you are putting your search value. InputfieldSelector uses the jQuery UI datepicker for the value input, and this has a constrainInput setting that's true by default. So if you set constrainInput to false you can enter free text into the input and it should just work. You have to set this option after the datepicker is initialised because PW doesn't provide any way of customising the datepicker options before initialisation (I've opened a request for that here: https://github.com/processwire/processwire-requests/issues/523). Here's how you might do it with some custom admin JS: $(document).on('focus', '.InputfieldSelector .InputfieldDatetimeDatepicker', function() { const $el = $(this); // Set constrainInput to false after a brief delay so that the datepicker has had time to initialise setTimeout(function() { if($el.datepicker('option', 'constrainInput')) { $el.datepicker('option', 'constrainInput', false); // Updating the option seems to cause the datepicker to hide so show it again $el.datepicker('show'); } }, 100); }); The result in Pages > Find as an example: Edit: you may know this already but you can add a custom row to InputfieldSelector where you can use any selector clause you like. So if you can trust your editors to get the field name right you could have a row like this: This is the better option if you want to save the value in a Lister bookmark for example, as it seems that InputfieldDatetime will convert a time string to the equivalent timestamp when it reloads so it then loses the "dynamic" aspect.

@Flashmaster82, ProcessWire tells you the requirements of a module when you retrieve the information from the modules directory: Also, the module readme is a good place to look for information about requirements.

Change the form method to "GET" and on the home page create links to URLs like "/case-studies/?selected=telecom"

I was going to suggest using inputfield dependencies as this would be the simplest option but it turns out there's a problem when using these with custom image fields: https://github.com/processwire/processwire-issues/issues/1889 So here's a hook instead. In this demo I want to show an error message if text_2 is left empty when text_1 is populated. You can adapt the names/labels/logic to your case. $wire->addHookAfter('InputfieldText::processInput', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; $page = $inputfield->hasPage; // Only for an inputfield associated with field "text_2" // Adjust the field name to suit if($field && $field->name === 'text_2') { // Only for an inputfield that is associated with a page using the custom image fields template // Adjust the template name to suit if($page && $page->template == 'field-images_custom') { /** @var InputfieldWrapper $wrapper */ $wrapper = $inputfield->parent; // Get sibling inputfield by label because the name will include a random string // Adjust inputfield label to suit $text_1 = $wrapper->children->get('label="Text 1"'); // Show an error message if text_2 is left empty when text_1 is populated if($text_1 && $text_1->value && !$inputfield->value) { $inputfield->error('A value for "Text 2" is required when "Text 1" is populated.'); } } } });

Try "has_parent!=2, include=hidden". If you only need a selector and not more advanced PHP logic then it's simpler to use the "Selector string" option rather than the "Custom PHP code" option.