Robin S

I'm not sure what the technical reason is for the 404 not being handled from ready.php, but as a workaround you could set a custom property on the $page object to indicate that a 404 should be thrown and then throw the 404 later, e.g. from a template file or from _main.php. // Your conditional in ready.php if($foo === 'bar') $page->throw404 = true; // In template file or _main.php if($page->throw404) wire404();

I'm not aware of anything changing that would make this module redundant, but it will be easy for you to check and find out. When using the Image & File Dependencies module, if your image field is named "image" you would use the selector string: _image>0

@dragan, this module works by hooking into Pageimage::size(), so it's only going to create an AVIF version of images that have been through some Pageimage sizing method.

The docs for the feature say: So if the URL being loaded is the URL for an actual page (regardless of whether it has a template file or not) then no URL Segment is going to apply. And if the URL resolves to a "car" page then the template file that's rendered won't actually be "car-maker.php" where your URL Segment code exists. If there's a car template file then it will be "car.php" that's rendered, and if there's no car template file then it will be whatever template file applies to your "404 Not Found" page.

@Fuzzy, you might something useful in these posts:

Thanks. No, because the icons are in a column labelled "Actions", with each icon representing an action you can take rather than a status that the PageTable item has. Plus the module has had its conventions for 8 years now and it would be pretty confusing for existing users if the icons suddenly reversed their meanings.

You might be interested in these modules too: https://processwire.com/modules/page-edit-per-user/ https://processwire.com/modules/page-edit-per-role/

It seems to work if you allow edit access on the parent template in the normal way via the PW admin... ...and then disallow editing on the parent template in a hook to Page::editable() $wire->addHookAfter('Page::editable', function(HookEvent $event) { /** @var Page $page */ $page = $event->object; $user = $event->wire()->user; // Return early if PW has already determined that the user is not allowed to edit if(!$event->return) return; // Don't allow users with the "editor" role to edit pages with the "colours" template if($page->template == 'colours' && $user->hasRole('editor')) $event->return = false; });

You can use a hook in /site/ready.php to set the page that images will be selected from, if you want it to be different than the default. The hook will work for both CKEditor and TinyMCE. $wire->addHookBefore('ProcessController::execute', function(HookEvent $event) { $input = $event->wire()->input; $page = $event->wire()->page; $pages = $event->wire()->pages; // Return early if the process is not ProcessPageEditImageSelect if(!$page || $page->process != 'ProcessPageEditImageSelect') return; // The ID of the page that is open in Page Edit $edit_page_id = (int) $input->get('edit_page_id'); // The ID of the page that images will be selected from by default // Often this is the same as $edit_page_id, but it can be different in the case of Repeater items, etc. $images_page_id = (int) $input->get('id'); // Check that the $edit_page_id is populated, otherwise the user will not // be able to manually choose a different page to select images from if(!$edit_page_id) return; // Optionally do some test using $edit_page_id and/or $images_page_id $edit_page = $pages->get($edit_page_id); if($edit_page->template != 'basic_page') return; // Set a different ID for the page that images will be selected from // e.g. select images from the home page $input->get->id = 1; });

I'm not sure if it's a solution to your issue, but I have this hook in every site (see the referenced issues for background): // Instead of rebuilding image variations, remove them and they'll be rebuilt when next requested // Fix for: https://github.com/processwire/processwire-issues/issues/1301 // Also see: https://github.com/processwire/processwire-issues/issues/1277 $wire->addHookBefore('Pageimage::rebuildVariations', function(HookEvent $event) { /** @var Pageimage $pageimage */ $pageimage = $event->object; $event->replace = true; $pageimage->removeVariations(); // Return expected output to avoid errors $event->return = [ 'rebuilt' => [], 'skipped' => [], 'reasons' => [], 'errors' => [], ]; }); It's only safe to do this if you do not allow image variations to be directly inserted into RTE fields. More info in this comment: https://github.com/processwire/processwire-issues/issues/1301#issuecomment-893957331

$pages->findRaw() will be helpful here. It's hugely faster than $pages->find() and easier to work with than SQL queries. You could do a couple of searches and connect the resulting data by repeater page ID. Example: // Ensure PagePaths module is installed so that URL is available to findRaw() $shop_data = $pages->findRaw("template=shop", ['title', 'url', 'locations'], ['nulls' => true, 'flat' => true]); // Here you could also get other fields from the repeater pages as needed $location_data = $pages->findRaw("template=repeater_locations, check_access=0", ['location'], ['nulls' => true, 'flat' => true]); $shops = []; // Loop over the shop data and get the lat/lng for each location, matching by repeater page ID foreach($shop_data as $id => $item) { $data = [ 'title' => $item['title'], 'url' => $item['url'], 'locations' => [], ]; $location_ids = explode(',', $item['locations.data']); foreach($location_ids as $location_id) { if(!isset($location_data[$location_id])) continue; $data['locations'][] = [ 'lat' => $location_data[$location_id]['location.lat'], 'lng' => $location_data[$location_id]['location.lng'], ]; } $shops[$id] = $data; } db($shops);

@Macrura, I'm not sure if your issue is the same as the caching issue that @adrian recently reported in the GitHub repo, but I've found a way to do some cache-busting in v0.5.2 so please try upgrading and see if that solves it. If not, could you please open a GitHub issue and we can continue the conversation there?

@Macrura, great, thanks.

Hi @Macrura, I can't reproduce that here. Could you please help with debugging by doing a couple of Tracy dumps after this line? bd($hanna_tags, "hanna_tags"); bd($tag_name, "tag_name"); For the Tracy bar to appear in the dialog you'll need to allow it in the module config, and maybe make the dialog a bit bigger than the default so it's easier to see the dump results.

Maybe this is safe, but it looks very risky to me. The ID here is coming from the URL, which is a type of user input. You would want to be 100% certain someone can't insert the default superuser ID 41 into the URL and then get logged in without a password and gain full access to the admin.

@ceberlin, thanks for the report, it should be fixed in v0.5.1.

In saveReady the page is just about to be saved and therefore output formatting is off, so all image fields (including single image fields) will be a Pageimages array.

@PWaddict, you would need to use a different hook for this because processInput is too early - it happens before Page Edit decides whether the page should be published so any changes to the published status made there would be overwritten. Something like this should work: $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'test_custom_images') { $unpublish = false; foreach($page->images_custom as $image) { if(!$image->text_1) $unpublish = true; } if($unpublish) $page->addStatus(Page::statusUnpublished); } });

@Charlie W, you can use an SQL query to match a date column by part of the date, e.g. by month. There are different ways you could incorporate this to find the pages you want, but one simple way is to first get the IDs of all matching pages, regardless of template, published status, etc, and then use those IDs as part of a PW selector. Demo: // First get the IDs of all pages where the month of the date value is February $field_name = 'date'; // The name of your date field $table_name = "field_$field_name"; // The table name is the field name prefixed with "field_" $month_number = 2; // i.e. February, or whatever month number you want to search for $stmt = $database->prepare("SELECT pages_id from $table_name WHERE MONTH(data) = :month_number"); $stmt->bindValue(':month_number', $month_number, \PDO::PARAM_INT); $stmt->execute(); $ids = $stmt->fetchAll(\PDO::FETCH_COLUMN); $ids_str = implode('|', $ids); // Then use the IDs in a selector where you are limiting by template, applying a sort, etc. $items = $pages->find("template=event, id=$ids_str, limit=3, sort=-date"); You can also match a date by just a day number or just a year, e.g. WHERE DAY(data) = :day_number WHERE YEAR(data) = :year

@ryan, is there any difference in terms of performance between using conditional hooks and doing the equivalent logic of checking the arguments and/or return value within the hook and returning early when a condition is not met? Personally I've preferred not to use the conditional hook syntax because I find it more readable to have PHP logic in the hook code, but if this was less performant I'd consider changing.

@adrian, the issue is resolved if I change line 111 of ConsolePanel.php to: $snippets[$i]['code'] = str_replace(\TracyDebugger::getDataValue('consoleCodePrefix'), '', file_get_contents($snippetFileName));

@adrian, yes, that's the code prefix I'm using. In the checkIfUnsavedChanges() JS function I logged the two pieces of code that are compared to see if there are unsaved changes: if(snippet && tab) { var snippet_code = snippet.code.replace(/\s+/g, ' ').trim(); var tab_code = tab.code.replace(/\s+/g, ' ').trim(); console.log("snippet_code: " + snippet_code); console.log("tab_code: " + tab_code); } So the snippet code that's loaded from tracyConsoleSnippets in local storage seems to have the prefix included.

In your field settings define "Template" for selectable pages but not "Parent". Check the "Enable link to create new pages?" checkbox that is added by the AdminPageFieldEditLinks module, but don't select anything in the "Parent for new pages created" field. Add the following hook to your /site/ready.php to define the parent dynamically. $wire->addHookBefore('InputfieldPage::render', function(HookEvent $event) { /** @var InputfieldPage $inputfield */ $inputfield = $event->object; $page = $inputfield->hasPage; $field = $inputfield->hasField; if($page && $field && $field->name === 'your_field_name') { $inputfield->parent_id = $page->id; } });

Thanks @adrian. The new light theme is nice. I used that as a starting point and made a few other opinionated changes (that are possibly only to my tastes and nobody else's) which I've added as a "Kiwi" theme and submitted as a pull request. I realise that with these extra changes there's a chance it might need tweaking if you make future updates to the Console panel, so I'm happy to take responsibility for maintaining the theme styles as needed into the future. An issue that I noticed when playing with the tabs: if I open one of my saved snippets that includes the "Code prefix" that is designed to be hidden in the console (in my case it has the PW namespace and PHPDoc comments for the API variables) the code is immediately detected as changed, which causes the alert when I try and close the tab.

@adrian, not sure what others think, but personally I like this style of tabs... ...more than the style in recent updates. In the previous version it's clearer that they are tabs, whereas in the newer version I find it all blends in with the code window. Maybe if the tab bar had a lighter background colour so it's more distinct?