Robin S

Hi @adrian, I think this probably isn't a Tracy issue as such but I thought you might have some insight on it... If I edit a field's settings (in this case the headline field) and set it to Autojoin then when I get a page whose template has that field then I can see the field value loaded on the Page object. But if I don't set Autojoin in the field settings and instead I set the field to join for a specific find() operation then I don't see the field value loaded on the Page object. (I'm using $pages->get() here but I think it is the same behind the scenes and I also tried $pages->find() and found the same issue). Or the older way: If I request the field value before I dump the Page object then it is loaded. I'm puzzled about why this is. Surely if the field value is joined during the find() then it must be stored somewhere on the Page object? Do you know if PW is storing these joined values somewhere that is invisible to Tracy? Or is this maybe a sign that there's a core bug and the joined fields are not actually being preloaded as expected?

@prestoav In the newly released v0.1.3 there is a config option to prepend $config->urls->root to URLs that start with a forward slash.

@ryan, thanks for this week's updates! @MoritzLost has sparked an interesting discussion about using PW with version control and he makes a comparison with Craft CMS. A couple of excerpts from his comments: Ryan, it would be great to get your voice in the discussion. We're at the beginning of the new year so what do you think about putting better compatibility with version control onto a roadmap for 2022?

As a general thing to make your life as a developer easier I suggest looking into virtual hosts for local development. That way your local site will be at something like mysite.dev and you can seamlessly move from local to remote without any URL issues. You can use virtual hosts with any LAMP/WAMP/etc, and in particular Laragon will give you an automatic virtual host for every site without needing any configuration.

I added a config field for this in v0.1.1. Let me know if this wasn't what you were getting at.

Lister Native Date Format Allows the date format for "created", "modified" and "published" columns to be set within a Lister or Lister Pro instance. Why? Lister formats the "created", "modified" and "published" columns as relative time strings and doesn't provide an easy way to change this without writing code. Sometimes a value like "3 weeks ago" is not precise enough and you want to see an exact date/time in these columns, perhaps only temporarily before switching back to a relative date. Details An icon is added near the top right of the Lister that reveals a dropdown where you can select from a list date formats that you define in the module config. The Lister will remember your chosen date format the next time you visit the Lister. If you have Lister Pro installed then each Lister Pro instance will remember the date format previously set for that instance. Configuration In the "Date options" field in the module config, enter a list of date formats that are compatible with wireDate(), one format per line. The default date format used by Lister is "rel". You can also set a default date format for native fields which will apply to all Listers that haven't yet had a date format chosen from the dropdown. https://github.com/Toutouwai/ListerNativeDateFormat https://processwire.com/modules/lister-native-date-format/

Another possible way to approach it is to find both normal and repeater pages and then convert the repeater pages into the non-repeater pages that contain them. FieldsetPage is a kind of Repeater. // Function to get the root container page when the supplied page might be a RepeaterPage function getRootContainer($page) { if($page instanceof RepeaterPage) { return getRootContainer($page->getForPage()); } else { return $page; } } // Get your Page Reference field $f = $fields->get('page_selector'); // Get the templates that contain the field (including Repeater templates) $tpls = $f->getTemplates(); // Implode to a string for use in a selector $tpls_string = $tpls->implode('|', 'name'); // Find pages (including Repeater pages) where the field is populated // The check_access=0 is so that Repeater pages are found when $user is a non-superuser $items = $pages->find("template=$tpls_string, check_access=0, $f.count>0"); // An empty PageArray that will hold the results $results = new PageArray(); foreach($items as $item) { // Convert any Repeater pages to their root container page and add to the results $results->add(getRootContainer($item)); } // Now use $results as needed

Personally I would use the admin page name in the URL but not the scheme/domain. So a relative URL but relative to the site root. In your example it looks like the admin page name is "admin" so the URL would be: /admin/page/edit/?id=1016 If you want to get the admin URL dynamically from $config for some reason then you just need to use the CustomAdminMenus::getMenuChildren hook method instead of entering your URLs as plain text in the admin.

Assumes "categories" is a multiple Page Reference field and that you have a hex colour defined on each category page: $wire->addHookAfter('ProcessPageListRender::getPageLabel', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'accommodation') { $out = ''; foreach($page->categories as $category) { $out .= "<span class='uk-label' style='background-color:$category->hex_colour'>$category->title</span> "; } $out .= $page->title; $event->return = $out; } });

There's no simple way because the home page is a special case in PW, but some similar topics with suggestions:

Please do, I'd be very interested to read that! It seems like this should be doable via a module in PW. I have a work-in-progress module that does something like this. It's not complete and haven't looked at it a while but it seemed like a promising avenue at the time. I think if the concept could be illustrated in a module then Ryan might see the benefits and then hopefully incorporate the features into the core. Seeing as you've clearly spent some time thinking about these issues, would you mind writing up a wishlist of what things you think PW should handle via files for the sake of version control? Fields and templates are the obvious things but you also mentioned translations which I wouldn't have thought of (I only work on single language websites) so it would be great to have a comprehensive list of problem areas for version control. Thanks in advance! ?

ProcessPageAdd preselects the template according to these principles: If there is already one or more child pages under the parent then it preselects the same template as used by the most recently added child page. If there are no child pages it preselects the same template as used by the parent page. But if that template isn't allowed to be used under the parent page then no template is preselected. So probably you recently added a page using the template that is only used in 5% of the cases, or that is the template of the parent page. You can force a particular template to be preselected in a couple of ways. 1. You can add a "template_id" GET variable to the URL of the "Add New" page. Example: "/processwire/page/add/?parent_id=1234&template_id=29" This might be a good approach if you are constructing your own custom link to the "Add New" screen but not so useful if you are just adding a new page via the standard PW admin. 2. You can use a hook in /site/ready.php to set a template_id GET variable to $input: // Before the ProcessPageAdd form is built $wire->addHookBefore('ProcessPageAdd::buildForm', function(HookEvent $event) { $input = $event->wire()->input; // Get the parent page the new page is being added under $parent_id = (int) $input->get('parent_id'); $parent = $event->wire()->pages->get($parent_id); // Return early if a single parent page isn't available or valid if(!$parent->id) return; // Do whatever check you need to identify if this is the parent you want to target if($parent->template == 'home') { // Get the template you want to be preselected $child_template = $event->wire()->templates->get('basic_page'); // Set the template ID to the "template_id" GET variable $input->get->template_id = $child_template->id; } });

@Richard Jedlička @wbmnfktr You can set a response code in your hook like this: http_response_code(400); So you can set 400, 307, or whatever you need. https://www.php.net/manual/en/function.http-response-code.php

I just tested in PW 3.0.191 Result: No wrapping <a> tag, button is disabled, button is visually identifiable as disabled, works as expected.

MarkupAdminDataTable::action() is a method that you call, not a property that you set. You would call the method like this: $table->action(['Home' => './']);

See here:

Added in v0.2.1

The trailing slash setting is something that applies to URLs rather than paths, i.e. $page->url rather than $page->path. Related GitHub issue with response from Ryan: https://github.com/processwire/processwire-issues/issues/273

Hi @adrian, thanks for the report. Please update to v0.4.4 and it should work.

I've added support for "Page (Autocomplete Single)" columns in v0.2.0.

Not a solution for VSCode but just for comparison... PhpStorm automatically adds the parent folder to the tab label as soon as two files are open with the same name. It's a nice feature.

Yes, it's InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/

Select Once Per Table Adds a setting to "Select", "Page (Select)" and "Page (Autocomplete Single)" columns in a ProFields Table field so that each option can only be selected once per table. Requires the ProFields Table module. There could be a number of situations where this module might be useful, but perhaps the primary situation is when you want to store extra information for pages that are selected in a Page Reference field. So instead of using a Page Reference field like this... ...you could use a ProFields Table field together with Select Once Per Table to store extra information for each selected page like this... The module ensures that pages/options that are already selected in the Table field are disabled as you add new rows or edit existing rows. Configuration To enable the module for any "Select", "Page (Select)" or "Page (Autocomplete Single)" column in your Table field, edit the column settings and add selectOnce=1. https://github.com/Toutouwai/SelectOncePerTable https://processwire.com/modules/select-once-per-table/

I'm not clear on how this relates to the Connect Page Fields module. Could you explain a bit more about how the module is involved in the error?

@Orkun, in case you missed it, Ryan has fixed this issue: https://github.com/processwire/processwire-issues/issues/1482