FireWire

Merry Christmas all! A new version in time for New Years? Now there's a great way to kick off 2025 😎

Many thanks as always! Keyboard hero. Probably wear a cape at your desk right?

@bernhard I am seeing some odd behavior and I think it's because I'm an American 🤣 When I add a new event on the calendar the date that I click is showing up on the event page has the month/day in the incorrect order (at least for us over here). This is the event date field value that I get if I click on December 9th, 2024 on the calendar inputfield. We write our dates incorrectly over here with mm/dd/yyyy. If I try to create an event on today's date (or any day greater than 12) then it renders NaN values since 16 isn't a valid month. I tried to double check that the locale was set correctly in case that was related, here's how that is configured. Also noticed that there's no option for en-us, I tried entering that manually but didn't see a difference. So I haven't had any luck with either en-gb or en-us. I can confirm that after creating the event and saving it with the incorrect date, I can go back and edit the date and it will save correctly in the right format. I created this one and it saved as October 12. I edited to December 10 and is saves/renders correctly. Let me know if there's anything I should do on my side to help fix. Humble request for en-us haha. Thanks as always 👍

@bernhard Awesome! Thank you!

I have a RockIcon field in a block that will only save if another field within the same block is changed. I noticed that updating a field such as text logs 'RockPageBuilder changed' to the console but selecting an icon from a RockIcon field doesn't. Would that indicate that the change to the icon field is not being recognized on save?

@bernhard I have a project in mind for my brother who sells things he makes online. Once I can get through a couple of projects, I'd like to build him a shop. Many thanks for your hard work and dedication. Such great contributions to the ProcessWire ecosystem.

Congrats on the launch @bernhard!

Maybe just for consistency? Optimization where the interpreter can reliably determine accepted types from hints alone without parsing default values? I can't tell how far into the PHP engine this goes and when it turns into a future exception perhaps how PHP handles this underneath the hood may itself change. A speculative example would be that the parser could ignore default values entirely if the arguments being passed/not passed to the function don't match the signature which could be the lone trigger for an exception in that case. This was frustrating for me as well. I couldn't find any information about type hints other than their usage. I could be entirely wrong about my thoughts above thanks to that. As for '?' vs. '|null', I like to use ? in type hints and spell out 'null' in the docblock. It's clear to read when the docblock is referenced by dev/editor tools that will display the full '|null' property description while still keeping the type definition in the method itself shorter so code lines take up less space in code editors. Personal preference, only thing that matters is consistency I guess. I haven't thought about a lot of this stuff in a long time though since I started declaring strict_types in every file and got set in my ways years ago. I consider that choice a luxury though because I'm not in a position where I ensure the kind of wide version support and foundational stability that ProcessWire does.

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 🤣

?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¿

Hi all (again)! I'm continuing to create buttons and have created a Github repo for all of the images. I've since added another after updating the initial post above. The repo will always have the latest preview, and new buttons. As mentioned above, the latest push contains cleanup and consistency for existing buttons as well as several new ones. Download from or fork the Builder Buttons Github repository Enjoy!

@bernhard Awesome as always. Thanks!

@modifiedcontent Virtualmin is open source and has a free community version. You can host multiple sites and have multiple users. Unless you're running a serious enterprise multi-server hosting business, I think Virtualmin would suit you just fine. What constitutes "use my websites professionally" more has to do with the features you expect to need. Virtualmin has an easy and clear breakdown of whether you're a person who actually needs a professional license at all, and "best" is very subjective. Personal preference, I've never liked cPanel but it's popular so some people think it's the best for them. I'm not an expert in server management software, but from what I've used I like Virtualmin the best. A downside for a more casual user is that the main admin (the one that manages users and has total control of the server) has a lot of features and may involve a little bit of a learning curve. It's likely not something you can't handle, but you have much more granular control over the server and users. I may have used Plesk in the past, probably through some managed hosting provider but it's not memorable enough to have an opinion. Given that the software you do choose is going to manage your server for the long term and there are open source/free versions, it's worth spending an afternoon trying them out. Spin up a cheap VPS, install the software, play around with it, then destroy the instance and review your notes. I've never been satisfied by just comparing specs or features "on paper" so to speak when it comes to server management software. It's something you have to feel out. Honestly- spending some time and getting a feel for the software is time well spent. You can be confident that the hours you spend up front now will ensure that you don't need to spend way, way, way more time later migrating all of your sites later because you find you can't live with it. Vultr has a marketplace that you can select an image to spin up a VPS with both cPanel and Plesk. It doesn't include Virtualmin or Vesta but those are essentially single line bash command installs. Just remember that if you're going to install Virtualmin, spin up a blank server with Linux and without any web hosting applications like Apache or MySQL- Virtualmin will take care of all of that.

@bernhard <section class="rpb-quote page-section rpb-block" data-rpbblock=5827 alfred='{&quot;icons&quot;:[{&quot;icon&quot;:&quot;edit&quot;,&quot;tooltip&quot;:&quot;Edit Block #5827&quot;,&quot;href&quot;:&quot;\/admin\/page\/edit\/?id=5827&amp;language=1027&quot;,&quot;class&quot;:&quot;pw-modal alfred-edit&quot;,&quot;suffix&quot;:&quot;data-buttons=\&quot;button.ui-button[type=submit]\&quot; data-autoclose data-reload&quot;},{&quot;icon&quot;:&quot;clone&quot;,&quot;label&quot;:&quot;&quot;Five International Architecture Festivals Worth Building a Trip Around&quot;&quot;,&quot;tooltip&quot;:&quot;Clone Block #5827&quot;,&quot;href&quot;:&quot;\/admin\/rockpagebuilder\/clone\/?block=5827&quot;,&quot;confirm&quot;:&quot;Do you really want to clone this element?&quot;},{&quot;icon&quot;:&quot;moveh&quot;,&quot;label&quot;:&quot;&quot;Five International Architecture Festivals Worth Building a Trip Around&quot;&quot;,&quot;tooltip&quot;:&quot;Move Block #5827&quot;,&quot;class&quot;:&quot;pw-modal&quot;,&quot;href&quot;:&quot;\/admin\/page\/edit\/?id=1&amp;language=1027&amp;field=rockpagebuilder_blocks&amp;rpb-moveblock=5827&quot;,&quot;suffix&quot;:&quot;data-buttons=\&quot;button.ui-button[type=submit]\&quot; data-autoclose data-reload&quot;},{&quot;icon&quot;:&quot;trash-2&quot;,&quot;label&quot;:&quot;&quot;Five International Architecture Festivals Worth Building a Trip Around&quot;&quot;,&quot;tooltip&quot;:&quot;Trash Block #5827&quot;,&quot;href&quot;:&quot;\/admin\/rockpagebuilder\/trash\/?block=5827&quot;,&quot;confirm&quot;:&quot;Do you really want to delete this element?&quot;},{&quot;icon&quot;:&quot;code&quot;,&quot;label&quot;:&quot;\/home\/modernismweek\/public_html\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.latte&quot;,&quot;href&quot;:&quot;subl:\/\/open\/?url=file:\/\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.latte&amp;line=%line&quot;,&quot;tooltip&quot;:&quot;\/home\/modernismweek\/public_html\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.latte&quot;},{&quot;icon&quot;:&quot;php&quot;,&quot;label&quot;:&quot;\/home\/modernismweek\/public_html\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.php&quot;,&quot;href&quot;:&quot;subl:\/\/open\/?url=file:\/\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.php&amp;line=%line&quot;,&quot;tooltip&quot;:&quot;\/home\/modernismweek\/public_html\/site\/templates\/RockPageBuilder\/blocks\/Quote\/Quote.php&quot;}],&quot;addTop&quot;:&quot;\/admin\/rockpagebuilder\/add\/?block=5827&amp;above=1&quot;,&quot;addBottom&quot;:&quot;\/admin\/rockpagebuilder\/add\/?block=5827&quot;,&quot;addLeft&quot;:null,&quot;addRight&quot;:null,&quot;widgetStyle&quot;:false,&quot;type&quot;:&quot;Quote&quot;}'> <div class="pt-4 px-5 md:px-10 lg:px-16"> <blockquote class="relative w-fit max-w-[60rem] mx-auto"> <span class="block absolute top-0 left-0 w-20 h-20 text-neutral-100 transform -translate-x-8 -translate-y-8 child-svg:w-full child-svg:fill-neutral-200"> <?xml version="1.0" encoding="utf-8"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 16 16" aria-hidden="true" role="img" aria-labelledby="title-bc232395-adec-49ef-877a-a8c1d379b1d1"><title id="title-bc232395-adec-49ef-877a-a8c1d379b1d1">Open Quote</title><path d="M7.39762 10.3C7.39762 11.0733 7.14888 11.7 6.6514 12.18C6.15392 12.6333 5.52552 12.86 4.76621 12.86C3.84979 12.86 3.09047 12.5533 2.48825 11.94C1.91222 11.3266 1.62421 10.4467 1.62421 9.29999C1.62421 8.07332 1.96459 6.87332 2.64535 5.69999C3.35231 4.49999 4.33418 3.55332 5.59098 2.85999L6.4943 4.25999C5.81354 4.73999 5.26369 5.27332 4.84476 5.85999C4.45201 6.44666 4.19017 7.12666 4.05926 7.89999C4.29491 7.79332 4.56983 7.73999 4.88403 7.73999C5.61716 7.73999 6.21938 7.97999 6.69067 8.45999C7.16197 8.93999 7.39762 9.55333 7.39762 10.3ZM14.6242 10.3C14.6242 11.0733 14.3755 11.7 13.878 12.18C13.3805 12.6333 12.7521 12.86 11.9928 12.86C11.0764 12.86 10.3171 12.5533 9.71484 11.94C9.13881 11.3266 8.85079 10.4467 8.85079 9.29999C8.85079 8.07332 9.19117 6.87332 9.87194 5.69999C10.5789 4.49999 11.5608 3.55332 12.8176 2.85999L13.7209 4.25999C13.0401 4.73999 12.4903 5.27332 12.0713 5.85999C11.6786 6.44666 11.4168 7.12666 11.2858 7.89999C11.5215 7.79332 11.7964 7.73999 12.1106 7.73999C12.8437 7.73999 13.446 7.97999 13.9173 8.45999C14.3886 8.93999 14.6242 9.55333 14.6242 10.3Z" /></svg> </span> <div class="relative z-10 prose prose-neutral max-w-none"> <em class="text-lg leading-relaxed tracking-wide sm:text-xl md:text-2xl"><div id=pw-edit-5 class='pw-edit pw-edit-InputfieldTextarea' data-name=rpbblock_textarea data-page=5827 data-lang='1027' style='position:relative'><div class=pw-edit-orig>One of the top five international architecture festivals in the world.</div><div class=pw-edit-copy id=pw-editor-rpbblock_textarea-5827 style='display:none;-webkit-user-select:text;user-select:text;' contenteditable>One of the top five international architecture festivals in the world.</div></div></em> </div> <footer class="mt-4 md:mt-6 pl-4 md:pl-10"> <div class="flex items-center justify-center md:justify-start space-x-4"> <div> <div class="text-base md:text-lg text-neutral-700"><span id=pw-edit-8 class='pw-edit pw-edit-InputfieldPageTitle' data-name=title data-page=5827 data-lang='1027' style='position:relative'><span class=pw-edit-orig>&quot;Five International Architecture Festivals Worth Building a Trip Around&quot;</span><span class=pw-edit-copy id=pw-editor-title-5827 style='display:none;-webkit-user-select:text;user-select:text;' contenteditable>"Five International Architecture Festivals Worth Building a Trip Around"</span></span></div> <div class="text-sm md:text-lg text-neutral-600 mt-2 pl-6"> <a href="https://robbreport.com/shelter/spaces/five-international-architecture-festivals-1235458827/https://robbreport.com/shelter/spaces/five-international-architecture-festivals-1235458827/" class="!no-underline" rel="noopener nofollow" target="_blank"> <span id=pw-edit-12 class='pw-edit pw-edit-InputfieldText' data-name=rpbblock_text data-page=5827 data-lang='1027' style='position:relative'><span class=pw-edit-orig>— Robb Report</span><span class=pw-edit-copy id=pw-editor-rpbblock_text-5827 style='display:none;-webkit-user-select:text;user-select:text;' contenteditable>— Robb Report</span></span> </a> </div> </div> </div> </footer> </blockquote> </div> </section>

Edit a widget? Not today.