Leaderboard

It’s been a fairly quiet week here at the ProcessWire HQ as it’s a Thanksgiving week where the kids don’t have school, which means less time in the office. This is the time of year when we think about what we’re thankful for, and I’m especially thankful for all of you and the ProcessWire community. Even with the holiday week, work continues on our next main/master version of ProcessWire. This week Bernhard and Adrian identified that ProcessWire doesn’t work well with PHP 8.4 due to some new deprecations introduced by this version of PHP. It’s a technical detail, but PHP 8.4+ wants a question mark before function/method arguments of named types that have a default value of null. So if the function arguments were (PageArray $items = null) PHP 8.4 wants it to be (?PageArray $items = null). Why? Who knows, perhaps not even PHP does, as “?” points directly to it being a question, one with no obvious answer. Perhaps it wants to make sure we really meant what we wrote, so the “?” is an “are you sure?”. Without question, the “= null” part is a pretty clear statement about what the intention is, no? I question the question mark, doesn’t this turn arguments into questions? Questionable arguments? Being so close to a new master/main version, there’s no question that we want to make sure it works with the latest available PHP version, questionable or not. So that meant adding new questions to 72 different core files, which you’ll find on the dev branch this week. There may be more questions yet to answer, but those are the instances I was able to find so far. There’s a tradeoff in that the questions were introduced by PHP 7.1, so it’ll produce a parse error on any prior versions of PHP. Meaning, our minimum required PHP version is now 7.1. Prior to today, it was 7.0 (actually, PW still even worked even on PHP 5.6, not that it matters). Similar questions will have to be added to modules before they are PHP 8.4 compatible to not throw deprecation notices, so I’ll be making some questionable updates to Pro and public modules in the coming weeks as well. Thanks for putting up with all my questions and have a great weekend! Please reply with your questions below.

?I've ?been ?type ?hinting ?parameters ?with ?question ?marks ?for ?so ?long ?I ?don't ?even ?see ?them ?anymore. @ryan Seconding @adrian's many thanks for the PHP 8.4 attention 🙌 Will we see any (Disjunctive|Normal)|(Form&Types) type declarations? Maybe a contest for longest function signature¿ Wait, did I just break my key¿

As someone who writes about as much C# as PHP, ? to indicate nullable parameters is familiar, although if they'd put the ? after the parameter type, it would have meant not having to remember a different position depending on language. At least we don't have to put another upside down question mark at the end of the parameter, for probably the majority of us who don't have Spanish keyboards. 🙂

Thanks Ryan for your hard work getting things ready for 8.4. While I see your frustration with PHP's change here, and appreciate your humorous commentary, I do actually think it makes sense when you consider that null is not a string or an array or some PW object, so there needs to be some way to explicitly state that null is an allowed option, rather than implicitly allowing it, which is exactly what the error states: "Implicitly marking parameter $var as nullable is deprecated". I actually think I prefer the use of union types, eg: (PageArray|null $items = null) rather than the obscure question mark, but as we figured out, that requires PHP 8. Anyway, thanks again for getting this implemented so very quickly so we can all start proper testing of 8.4 with our projects.

They need to get us used to some more obscure syntax before they introduce the next logical step - mandatory compilation. So be happy they are boiling the frog slowly and we still have a few more happy years just scripting.

Try maybe: if($user->language->name == "en"){ //Processwire magic }

Hi, This is a basic module to add some classes and css to teh logs list page based on the amount of time since the log has been edited. less than a minute: Red -> purple -> grey less than a week https://github.com/benbyford/HighlightRecentLogs I hooked to the ProcessLogger module ___execute() function and basically overwrote it. Felt abit nasty to me, I wondered if there would have been a better way of doing it?

Went down a rabbit hole on this one... Really curious why they chose a structureless document format like markdown when there are rich and mature data standards like Schema.org. The foundational work would have already been completed, the syntax well established/adopted, and there could be a lot of areas where the wheel may not need to be reinvented. Already exists on millions of websites and generators/parsers already exist for it- adoption by devs and orgs could adopt it so much more quickly with updates to existing packages/libraries. Almost all of the examples they give on the llmstxt website could be satisfied out of the box and if not, remedied by extending the specification. Maybe I'm missing the boat on this one, but is their rejection of an existing data structure due to the fact that they want LLMs to read the content "naturally"? Are LLMs incapable? If that's the case, should LLMs be giving anyone programming tips... I know I've veered off the topic of this post, but this proposal is 3 months old and curious if it has any legs. ANYWAY. Considerations for a module... How would it handle different information at different URL paths? Would it just dump all content into a single file? May create a massive file that starts to introduce performance issues on larger sites with things like blogs. This issue filed on the proposal Github repo brings up multiple URLs but the proposal itself doesn't seem to have anything concrete that takes this into consideration. Thinking about this out loud because creating a module to satisfy this need may end up being a more generalized module. I think this would end up turning into a Markdown generator, if not a library outright. I did a good amount of searching and there are tons of PHP packages that parse MD but I couldn't find any that generate MD from values. If that library existed, the module would be a lot easier to build. In the case of this module we'd essentially be building two versions of the same site because Markdown is as concerned about presentation as it is about content rather than just logic. Each field would have to be configured for rendering in MD. The llmstxt example of Franklin's BBQ is a good illustration. They have an unordered list of weekly hours, but their menu is formatted as a table. In that example, either one could be rendered as a list or table. Assuming we are using a repeater for hours and a repeater for menu items, each field would need to have settings for how it should be rendered (list or table). In the case of a table, fields for table headers need to be mapped and the subfields in the repeater mapped to column values. I don't even know what the settings would look like to render the business hours as a list according to the example. I'm thinking that putting all of the configuration into a module would be a significant challenge. I'm not sure that this proposed standard lends itself well to creating content for the markdown file via a user-friendly UI. It may need a developer to handle it all separately. This is one of the reasons I mentioned Schema data. It would be trivial to implement a Schema object, we already to for Google's structured data. The biggest lift would be to write a library that the developer uses to render the MD data and minimizing per-field configuration, and probably making the module just a formatter that outputs Markdown using defined methods. Here's a hypothetical implementation that uses page classes and an imaginary MarkdownGenerator module. This would render something like the Franklin's BBQ example in the link above <?php namespace ProcessWire; // site/classes/HomePage class HomePage extends DefaulePage { public function renderLlmsMarkdown(): string { $md = wire('modules')->get('MarkdownGenerator'); return $md->render([ $md->h1($this->title), $md->quote($this->summary), $md->text('Here are our weekly hours'), $md->ul( array_map( fn ($row) => "{$row->days}: {$row->hours}", $this->pages->get(1012)->operating_hours->getArray(), ), ), $md->h2('Menus'), $md->ul( array_map( fn ($menuPage) => $md->link($menuPage->title, "{$menuPage->httpUrl}/llms.txt"), $this->get('template=menu')->menus->getArray(), ), ), ]); } } // site/classes/MenuPage.php class MenuPage extends DefaulePage { public function renderLlmsMarkdown(): string { $md = wire('modules')->get('MarkdownGenerator'); $markdownItems = array_map(function($menuSection) use ($md) { return $md->render([ $md->h2($menuSection->title), $md->table( ['Item', 'Price'], array_map( fn ($item) => [$item->title, $item->price], $section->menu_items->getArray(), ), ), ]); }, $this->menu->getArray()); return $md->renderBlocks($markdownItems); } } // site/init.php foreach ($pages->find('template=home|menu') as $llmPage) { $wire->addHook( "{$llmPage->url}llms.txt", fn (HookEvent $e) => $e->pages->get($llmPage)->renderLlmsMarkdown() ); } That should really leverage caching in the real world. This approach will render an llms file at each individual URL for pages that are configured. This standard proposal seems to be taking a non-web approach and, as mentioned in that Github issue above, haven't considered leveraging web URLs but instead creating a stack of separate linked MD documents that an LLM reads like a book at the root URL. Since the standard doesn't say "look for llms.txt at every available url', then any pages with llms data will have to be specifically referenced/rendered on either the root llms.txt document or another llms.txt document that is or has an ancestor that is referenced in the root document. This follows the BBQ example, but just uses actual URLs rather than generating a stack of separate MD documents at the root. I assume you could just hook file names that contain Page IDs or something, but this makes more sense to me. Seems like an incredibly efficient way to build a whole new internet just for robots without any value provided to the people doing the work 🤔 At the very least I want a promise from someone that my life and the lives of my family will be spared when Skynet takes over. tl;dr Creating a module specifically to render llms data may not be the most efficient way to go about this A module that puts configurations into the UI would have to be extremely complex and account for the many types of fields available in ProcessWire Accounting for fields requires that each type of field is limited to the type of MD is can generate if the module attempted to make everything configurable The best way would probably be to create fields that will contain the content and then have your code do the rendering This is basically just creating two websites. One for people and one for LLMs Because this proposed standard has chosen markup over a logical data structure, it's probably always going to be on the shoulders of the developer unless they change something Another challenge is their expectation of additional content management: If this is important enough then there may be a need to manage LLM consumable information separately in fields that contain content sufficiently dumbed down for LLMs. Maybe the real module here is one that connects to an LLM API which auto-summarizes the content to then be used when creating MD files that describe the content to other LLMs. Solution: a library or Module that takes inputs and renders Markdown. Wouldn't be anything specific to AI. Or this standard could be tossed and we can just render structured data on the web page so LLMs can use the internet as a natively hyperlinked set of documents located at stable and discoverable URLs... Having thought this out I think even less of this standard than when I first read the proposal 🤣

Thanks a lot @Cybermano That worked flawless.

Hi @torf, maybe I didn't get it at all or maybe I didn't explain well my idea. So I'll try again... 😉 Surely I could be wrong, but for me a PageArray is not only for admin side, but all the pw pages collected into a php variable created with pw selectors in a script file. For shortness I have created 2 pages with two repeaters each (repeater name is "multipoints"), with a title and a leaflet map field (named 'fm_mappa') into. This is the simply code for testing. Please note that I didn't get the repeater with a foreach statement, but with a pw search with a selector for all the templates with name equals to "repeater_NAMEOFTHEREPEATER", as pw builds. Obviously into your selector you can build your search to the desired points, e.g with sorting or something other. echo $pagesWithMultipointsRepeater = wire('pages')->find('template=repeater_multipoints'); if (count($pagesWithMultipointsRepeater)){ $map = $modules->get('MarkupLeafletMap'); $options = array( 'height' => 800, 'markerColour' => 'red', ); echo '<div class="g-mb-25">'; echo $map->render($pagesWithMultipointsRepeater,'fm_mappa',$options); echo '</div>'; } The numbers before the map are the repeater ids (note the "echo" on the first line of the code). And these are the admin pages: I hope that's clearer.

That works! Thank you so much! <?php if($user->language->name == "en-gb"): ?> <script src="<?php echo $config->urls->templates; ?>assets/scripts/cookieconsent-init-en.js" async></script> <?php else: ?> <script src="<?php echo $config->urls->templates; ?>assets/scripts/cookieconsent-init-no.js" async></script> <?php endif; ?>

Deprecation warnings say, that it potentially may not be ready for 8.4.2 or 8.4.3 or any other further version. But in my understanding, it is ready for PHP 8.4.0 and 8.4.1. 🙂 If the deprecation warnings bother you, you can disable showing only those messages with a call of PHPs set_error_handler(): /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { return true; // true | false = suppress further processing } // 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); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ I often use this directly in site/config-dev.php, when I want to collect them, but only show them collected at the end of pages in dev local. /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { // CHECK / CREATE COLLECTION CONTAINER if (!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if (!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } // DO NOT SHOW THIS KNOWN THIRD PARTY ONES : $hideThisOnes = [ //'FileCompiler', 'Duplicator', 'ProcessCustomUploadNames', ]; foreach($hideThisOnes as $item) { if (preg_match("/{$item}/", $errfile)) return true; } // ADD IT TO THE COLLECTION $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } // 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); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/

https://github.com/processwire/processwire-issues/issues/2000

I'm reading Head First Design Patterns, because a recommendation of @da² in this beautiful post.

UPDATE 2022 Simple and powerful - put this at the end of your config.php file: $localConfig = __DIR__ . "/config-local.php"; if (is_file($localConfig)) include $localConfig; Then put all local settings into config-local.php (same concept for DEV/STAGING/PRODUCTION): <?php namespace ProcessWire; /** @var Config $config */ $config->debug = true; $config->advanced = true; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbHost = 'db'; $config->userAuthSalt = '1234'; $config->tableSalt = '1234'; $config->httpHosts = ['xyz.ddev.site']; // this prevents logout when switching between // desktop and mobile in chrome devtools $config->sessionFingerprint = false; // RockFrontend $config->livereload = 1; // RockMigrations // $config->filesOnDemand = 'https://your-live.site/'; $config->rockmigrations = [ 'syncSnippets' => true, ]; // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/Users/xyz/code/yourproject/', 'numLogEntries' => 100, // for RockMigrations ]; $config->rockpagebuilder = [ "createView" => "latte", ]; -------------------- OLD POST from 2018: Have you ever come across the situation where you needed to change your config.php file for local development? Have you ever come across this warning? Say goodbye to this little annoying tasks Some of you might know that you can have a separate config-dev.php file for local development. This is nice, but also needs some setup (for example excluding this file for git upload) and there is still some danger of uploading this file to a place where it should not be... The other option was to keep the database settings for your live and dev server in sync - also not easy and maybe not the best... My solution is as simple, fast and I think it should be even safer than the other options. Just put these lines at the end of your config.php file: if(strpos($config->paths->root, 'C:/www/') === 0) { $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER[HTTP_HOST]]; $config->debug = true; } elseif(strpos($config->paths->root, '/var/www/vhosts/') === 0) { $config->httpHosts = []; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->debug = false; /** * Redirect to HTTPS * ATTENTION: This will NOT work with ProCache enabled! Use .htaccess instead */ if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){ $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $redirect); exit(); } } else die('wrong config.php'); Having a separate config-dev.php file also makes it necessary to keep both files in sync. That was my first idea: To include the original config and then overwrite settings. But it's just simpler the other way round: Using the default config.php file and overwriting settings there.