Leaderboard

Hey @FireWire thx again for sharing your block thumbnails! I have just made it a lot easier to explore/find/use them and added this field to the module config screen where you can just click on the icon and it will copy the name to the clipboard that you can then just paste into your "thumb" property of the block's info method 😎

Today a client asked if they can have a page where they can upload internal documents that are only visible to logged in users... I thought the easiest solution is to make the page unpublished and make sure nobody can publish it. This is done with a checkbox that is only visible to superusers and when checked, the page always adds the unpublished state on saveready: <?php // in init() of the Site.module.php wire()->addHookAfter('Pages::saveReady', $this, 'lockPage'); // the hook protected function lockPage(HookEvent $event): void { $p = $event->arguments(0); $locked = $p->getFormatted(RockMigrationsConstants::field_lock); if (!$locked) return; $p->addStatus(Page::statusUnpublished); } And another hook to remove the publish button (which is why I found this thread and thought it might make sense to share this solution): <?php // init() of Site.module.php wire()->addHookAfter('ProcessPageEdit::buildForm', $this, 'hidePublishButton'); // the hook protected function hidePublishButton(HookEvent $event): void { $p = $event->process->getPage(); $locked = $p->getFormatted(RockMigrationsConstants::field_lock); if (!$locked) return; $form = $event->return; $button = $form->getChildByName('submit_publish'); $form->remove($button); } This will also remove the copy of the publish button 🙂

Hi all, just added a repo for the 3.0.246 rmaster branch release even if very few changes (only two sentences about a potential page "trash" status error) since the 3.0.244 one https://github.com/virtualgadjo/pw-30246-lang-fr have a nice day

Ha! Twenty-three months later I have the same exact problem. And twenty-three months later, I find @Robin S’s excellent answer. Thank you so much — again!!

Hi @virtualgadjo - in PW the system dates (created, modified, published) always return a timestamp regardless of whether outputformatting is on or not. In the latest version I have added new options for system fields to export so there are now formatted versions along with the timestamp ones. I though this was better than just using the Format Export to control this because I can see wanting these independent of whether the rest of the fields are formatted or not. Hope that helps.

I found that all I needed at the end of my config.php was $config->dbInitCommand = "SET time_zone = '+08:00' "; and all is good, warning gone. Thanks again.

Regarding multi-language fields such as TextLanguage, TextareaLanguage, and PageTitleLanguage: When multi-language fields are shown in Page Edit mode, I often use them next to non-multi-language fields. That makes the page appear a bit disorganized and cluttered because multi-language fields vs non-multi-language fields don't align horizontally. The reason is that multi-language field have "language switcher tabs" that forces the field to "jump down" whereas normal fields stay in the normal position. See screenshot 1. It makes me sea sick! ? Suggested solution is to move the "language switcher tabs" up so that it aligns with the field label. See screenshot 2.

You can also do this with the Pro modules. They are just PHP scripts like other modules. And you get access to the internal support forums of the corresponding pro modules. Of course you can also just buy the modules and not use them to support Ryan 😉

If you want, you can filter them out and focus more on your essentials. But first things first. There is a whole list of different PHP errors, warnings and hints (notices). The one we are interested in is E_DEPRECATED. These messages indicate that a used PHP function somewhere in the code is no longer supported in a future, i.e. higher PHP version, not the actual used one. Example: The days (February 2022) I have changed my developer machine to use the latest PHP version 8.1.2. The last PHP 7.4+ is still supported for 9 months from today on, PHP 8.0 still for 1 year + 9months, PHP 8.1 for 2 years+ 9 months, and all other PHP 8+ versions each plus one more year. So the point is clear now, right? It will be year(s) before PHP 9 is on the schedule. ? Currently in v8.1.2, depending on what code I run, I get notices that certain PHP functions will no longer be available starting with PHP 9. (PHP 9! see above). So currently these functions are safe and supported functions, as in past versions as well as in all further PHP 8+ versions(!). No matter how many additional PHP 8+ versions there will be. ProcessWire by default allows us to suppress ALL output, or show ALL output, by the boolean configuration variable "$config->debug". This is good and right, because on a production site you should always suppress all those outputs. On a developer machine it usually shouldn't bother you if there are also E_DEPRECATED hints included. But if it does, you can filter them out as follows, for example. In your site/config.php you can define a own error handler function and load / bind it on your developer machine only. As a proof of concept or simple example, I added the following function to my site/config.php /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { if(!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if(!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ With the following call, also located in my developer machines site/config.php file, I bind it to all raising E_DEPRECATED warnings ONLY! So we are sure and free from all other types of errors, warnings, hints, etc. // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); (read more on php.net) Now you will not see any of the deprecated notices any more, cluttering your screen. Neither in the front end nor in the backend. But they are all collected in our bag. ? A simple loop in the site/templates/admin.php, before the controller.php is called, can display any of it, maybe to the superusers only, for example: <?php namespace ProcessWire; // IF WE HAVE CACHED PHP DEPRECATION WARNINGS, SHOW THEM IN THE ADMIN, FOR SUPERUSERS ONLY if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG']) && $user->isSuperuser()) { foreach($GLOBALS['DEPRECATION_WARNINGS_BAG'] as $deprecatedMessageItem) { $deprecatedMessageItemMSG = "PHP DEPRECATED (v". PHP_VERSION .") = \n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[0]} : [{$deprecatedMessageItem[1]}]\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[2]}"; $this->message($deprecatedMessageItemMSG); } } require($config->paths->adminTemplates . 'controller.php'); If you want to show them on the front end to, it belongs to how you have organized your output strategy. I use a delayed output with _init.php and _main.php, where I have a special function for adding all kind of debug messages, that gets displayed on the end of the site, after the footer. Simply adding the whole collected array is enough for my information: if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { mvdr(['DEPRECATED ('. PHP_VERSION .')' => $GLOBALS['DEPRECATION_WARNINGS_BAG']]); // add it to the debug output region var } The outputs in admin then may look like this Or the very basic info for me on front end

In the "Selector string" setting for "Selectable pages" you can use "page" to refer to the current page, but only if you also specify a subfield using dot syntax. In your case you would use page.id to exclude children of a parent: template=item, parent!=page.id Unfortunately I don't think this is documented anywhere.

Huzzah! Managed to figure it out. For anybody else with this issue, there is a setting for the Page Selection fieldtype to allow UnPublished page at the bottom of the Details tab.