Leaderboard
Popular Content
Showing content with the highest reputation on 12/01/2024 in all areas
-
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.4 points
-
Hello, Because I was in need of such a thing but there was nothing that I could find, I had to create my own. I'm sharing here, so maybe someone will find it useful. My second module, Use at your own risk, there may be some mistakes, please if you find them, let me know! Right now the module mostly works with datetime field!!! This was what I was going for actualy. Description Page Automation Module for ProcessWire Description: The Page Automation module automates various page management tasks in ProcessWire, such as copying, cloning, deleting, publishing, hiding, and more based on predefined conditions. It allows users to set triggers based on a page's field values and perform automated actions without manual intervention. The module integrates with LazyCron for scheduling periodic checks. Key Features: Perform actions like copy, clone, delete, publish, hide/unhide automatically. Configure conditions based on date/time fields (e.g., "older than 1 day"). Schedule actions with flexible cron intervals (every minute, hour, day, week, or year). Supports applying actions only to pages using specific templates. Option to assign a different template to cloned/copied pages. Logs all automated actions for easy tracking. Requirements: ProcessWire 3.x or later. LazyCron Module (it won't work without it). Setup Instructions: Install the module through the ProcessWire Modules directory. Configure the conditions, templates, and actions via the module settings. (Optional) Install LazyCron for time-based automation. Verify that the automation_processed checkbox field is automatically created for tracking processed pages. Once configured, the module will automatically handle repetitive page management tasks based on your specified conditions, saving time and effort. Important! Uppon install the module will create a new field "automation_processed" which you must add to the main template (template for action or make it global), if not you'll end up with a bunch of copies. This field tells the module that the page was already proccessed, so it will leave it alone. PageAutomation_preview.mp4 I hope u like it 😉 You can download it here: PageAutomation.zip4 points
-
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.4 points
-
Hello community, to my surprise and delight, my module “FrontendAutoReload”, which was previously only published on Github and used exclusively by me, was presented in the ProcessWire Weekly Newsletter #545. And because I haven't encountered any problems using it so far, I'm in the process of submitting it to the module repository. It's basically a little helper for ProcessWire template development, which automatically hits the refresh button in your browser each time a change in the template folder is detected. Not groundbreaking but a convienient timesafer. I would therefore be delighted if it could also be of some help to other developers. For information on how to use it, check out FrontentAutoReload on Github. If you have any questions, don't hesitate to ask them.3 points
-
?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¿2 points
-
Hey @Ivan Gretsky Going fine, just been busy and all — so nothing new really 🙂 I don't have new features in the works right now, mostly because for the type of projects I've been working on recently I've felt that it's more about the stuff that's outside Wireframe than in the scope of it that needs work. But since you asked, there are some ideas I've been thinking of adding. Either as a part of the framework, or as a stand-alone things. One of these is Composers, likely similar to what they've got in the Sage theme for WordPress: https://roots.io/sage/docs/composers/. Honestly still not sure how good an idea that one, but I can see some benefits, and it might be fun to experiment on 🙂 Makes sense to me, so I've added a new method for that. Usage looks like this: $wireframe = $modules->get('Wireframe'); $wireframe->initOnce(); // pass in an array of Wireframe dir names, or null to create all; defaults to null, // default value is an array with dir names as keys and disk paths as values $dirs = $wireframe->createDirectories([ 'lib', 'views', 'layouts', 'partials', 'resources', 'components', 'controllers', 'dist', 'resources', ]); Note that this is not well tested, and there may be situations I've not accounted for 🙂1 point
-
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?1 point
-
You can also click on the modified column headline and it will sort by last modification date 🙂1 point
-
1 point
-
Hey @Robin S - yep, all you need to do is populate: $this->output = 'this'; $this->output .= 'and that'; return true; inside the executeAction() method.1 point
-
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 🤣1 point
-
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. 🙂1 point
-
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!1 point