Leaderboard
Popular Content
Showing content with the highest reputation on 01/08/2025 in all areas
-
View website: ID Studio Web Agency We have been working on the ID Studio website for quiet some time using ProcessWire extensively for ourseleves and 90% of all our clients. This post will highlight some features we have implmented and also show off some of the hidden functionality. A quick overview is as follows: Custom web design of course 🙂 Front-end uses Canvas and Three.JS The core objective for us is to get users engaged, reviewing the showcase and services, then getting in touch The showcase and blog have alot of content We hide the ID Lab and About section in the footer but there if folks want to dive in and have the time Development features include: We use the form builder system with some custom modifications 3D tools and management Linking 3D elements to HTML elements Repeater matrix for content panels and lots more, best way is to see it on the video overview below ID-Overview.mp4
8 points -
Happy new year everyone! I've been working on adding multiple tab support for the console panel. It works in conjunction with the snippets panel so you can load up multiple snippets, or create any number of temporary (unsaved) tabs of code. Each tab has its own execution history stack and the last result for each tab is also maintained so you can flip between tabs to see the differences between results. It automatically names tabs like a typical code editor does: Untitled-1 initially, and then using the first line of code. Of course when you save the tab to a snippet, the tab name will be that of the snippet filename saved to disk. I'll push it live soon, but if anyone sees this and would like to test and provide feedback beforehand, please take a look at this branch: https://github.com/adrianbj/TracyDebugger/tree/console-tabs Thanks!
3 points
-
Hi there, I'm experiencing unexpected behavior with markup regions where multiple pw-append actions are being processed in reverse order. I have been using markup regions for several years in multiple projects and never came across this. There are no project specific potential causes for my problem that I could identify. Involved HTML markup syntax is correct. Setup Delayed output strategy with site/templates/_main.php (simplified): <html> <head> </head> <body> <main id="maincontent" class="content"> </main> </body> </html> site/templates/products.php: <div class="bg productsintrobg" pw-append="maincontent"> <!-- Products Intro Section --> <div class="container"> <!-- Products Intro Content --> </div> </div> <div class="bg productcatsbg" pw-append="maincontent"> <!-- Product Categories Section --> <div class="container"> <section class="productCats teasers row"> <!-- Product categories content --> </section> </div> </div> Expected Behavior Since products.php executes before _main.php and contains region actions (pw-append) that should be processed in order, the final output should show: Products Intro Section Product Categories Section Actual Behavior The sections are rendered in reverse order: Product Categories Section Products Intro Section Technical Context According to the Markup Regions documentation: Since products.php is processed before _main.php (using $config->appendTemplateFile = '_main.php'), the region actions in products.php are technically output "before" the <html> tag and region definitions in _main.php. Therefore, the implementation follows the documentation correctly, but the output order is reversed. Current Workaround Changed first section from pw-append to pw-prepend to achieve desired order: <div class="bg productsintrobg" pw-prepend="maincontent"> <!-- Products Intro Section --> </div> <div class="bg productcatsbg" pw-append="maincontent"> <!-- Product Categories Section --> </div> MarkupRegions Debug Output (shows wrong order of processing): • APPEND #maincontent with <div class="bg productcatsbg" ... +24 bytes><div class="container"> <section class="productCats teasers row"> … 14986 bytes</div> • APPEND #maincontent with <div class="bg productsintrobg... +26 bytes><div class="container"> <article class='intro row'> … 1264 bytes</div> • 0.0014 seconds Environment ProcessWire version: .3.0.243 PHP version: 8.1 (same behavior with 8.2) Has anyone experienced this before? Couldn't find related forum posts or github issues2 points
-
That is defintiely a very wide monitor 🙂2 points
-
The plan was to merge dev to the main branch today, but I’m still working through a couple of GitHub issues that I’d like to resolve or finish the conversation before finalizing the 3.0.244 main version. One example is this issue report where it was pointed out that there are some issues with UTF-8 page names. ProcessWire uses PHP’s IDN functions to manage conversion to and from the non UTF-8 version of the URL. PHP 7.4 changed the default arguments of the idn_* functions to settings that made them not work 100% for page names in a few cases, which I didn’t realize before this week. But this is not an issue that I can just fix and be done with it… There may already be page names in any given installation that are affected by the post PHP 7.4 behavior. If I were to just fix the issue, then some affected pages might no longer match when accessed directly by URL. So this had to be a carefully considered fix. What I ended up doing is fix it for any new PW installations that occur after this weekend. PW keeps track of its installation date, so can do this by way of its $config->installedAfter(“2025-01-05”) function. Existing installations will keep the imperfect behavior. Presumably it doesn’t affect that many installations since it only came to light last week and PHP 7.4 was released roughly 5 years ago. Nevertheless, existing installations that want the “fixed” behavior can get it by specifying this in /site/config.php: $config->pageNameWhitelist = 'v3' . $config->pageNameWhitelist; That essentially says to use version 3 of the page name conversion. Version 2 will also work fine, but may be slightly slower since it uses a dedicated Punycode library. And version 1 is the one that worked correctly until PHP 7.4, and still works mosts most of the time, but can produce imperfect results in some cases. Installations prior to 5 Jan 2025 use v1 by default and installations after 5 Jan 2025 use v3 by default. Chances are few (if any) will want to specify the version manually like above, but the option is there, just in case. That’s one example of why I’m waiting another few days before the dev branch merge to main. Another is that Adrian mentioned double-clicking on the “Move to Trash” button [in the page editor] makes it permanently delete the page rather than trash it. While I can’t duplicate that, despite multiple attempts, I just want to make sure there’s not something that needs fixing there. But unless any major new issues turn up, by this time next week we’ll merge to main and bump the version to 3.0.244. Thanks and Happy New Year!2 points
-
This could also be a browser issue. One example would be a cached 301 redirect from an old staging install on the same URL. Modern browsers are caching these forever and it's a pain to make them forget the redirects.1 point
-
In your hook posted above you use “indexPages()”, but the correct one would be “indexPage($page)” without the s at the end. Your hook creates a completely new search index each time, not only for the changed page but for all pages. You have to use something like this (not tested) $wire->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments(0); $event->modules->get('SearchEngine')->indexPage($page); $event->wire('log')->save('Page saved', "Page ID: $page->id / Page Name: $page->name / Page Parents: $page->parents"); });1 point
-
Hey @Christophe this has come up in the RockMoney thread already. You need to install/enable the Intl extension for PHP on your system. I have added a check for this that should throw a more helpful error message and I have added it to the docs about RockMoney!1 point
-
ProcessWire should soon be listed under the DDEV Quickstart List: List: https://ddev.readthedocs.io/en/stable/users/quickstart/ PR: https://github.com/ddev/ddev/pull/68791 point
-
Thanks for the additions, great work!1 point
-
@FireWire @Jonathan Lahijani @gebeer I've created a demo module that shows how to use the new config migrations. Please note that it needs the latest RockMigrations version from the dev branch! https://github.com/baumrock/ConfigMigrationsDemo1 point
-
@bernhard How do RM's config migrations work when it comes to creating pages, since it doesn't support page creation? So let's say I wanted to create /colors/ with child pages red, green and blue. I would have: /site/RockMigrations/templates/colors.php /site/RockMigrations/templates/color.php /site/RockMigrations/fields/color.php To make the 'color' single-select page field use /colors/ as a parent page and 'color' as a template, the /colors/ page needs to be created using the 'colors' template and red/green/blue need to be created with the 'color' template. Where would the code go for creating those pages if now the code for fields and templates are done in the new "config migrations" way?1 point
-
Sounds like a new module coming. RockEstimator. 😁1 point
-
Ok then it's likely because your PHP does not have the Intl extension installed. Please do that, then it should work!1 point
-
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 admin Modules upload by File upload. 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.zip1 point
-
Oh my... just had to try it. 😂 I'm even more confused now than usual.1 point
-
After probably 12 years with Processwire, I just discovered that pressing the 🌲 tree icon link, in the breadcrumbs, opens a modal with the page tree.1 point
-
That video made me want to look more into that ProcessWire CMS he was talking about. Sounds great. 😬1 point
-
ProcessWire is mentioned in at least the first 6 minutes. I had already stumbled upon this video before but hadn't really watched it. Part of the video description: "Benjamin Milde takes some of his favourite CMS’ – ProcessWire – underlying implementations for data querying and storage layout and reimagine those using ecto."1 point
-
@MarkE If it's a Process module (i.e. extends the Process class) then that's a module designed to be an application in the admin, and that module is only executed when clicked on in the navigation (assuming the user has permission for it). It sounds like you also need a module that has the "autoload" enabled, meaning that it either loads every time PW boots, or under some autoload condition that you define. Process modules aren't meant to be "autoload" modules. Process modules are interactive applications, creating and processing forms in the admin. Autoload modules hook into ProcessWire and adjust runtime behavior. These are very different responsibilities, so you want 2 modules: one Process module and one autoload module. For instance, there's FormBuilder and ProcessFormBuilder, UserActivity and ProcessUserActivity, ProCache and ProcessProCache, etc. If you absolutely had to have it all in a Process module, you could, but you'd have to do your own permission check in the execute() method(s), and your module would appear in the admin navigation even for people that didn't have access to it. It's cleaner to do it with two modules, and one can install/uninstall the other just by using the "installs" property in your module info for one of them, and "requires" for the other.1 point
-
Just a note to say that I've added a new Page Meta section to the Request Info panel. This displays all meta entries for the page, along with links to open the entries for editing directly in Adminer. Speaking of Adminer - it was recently updated to AdminerEvo and I changed the way links from Tracy to open Adminer work - they now open the bar panel version which I believe is a much nicer experience than the standalone Adminer page. I also added links to edit the values of all fields within the Page Edit interface. If the field has multiple values, it will open Adminer showing all entries instead. This is of course optional, so you can visit the Adminer settings (now merged into Tracy's settings) to turn this off if you prefer. Please note that when you first upgrade, you will likely need to do a modules > refresh to get Adminer to load properly the first time.
1 point
-
Hi @d'Hinnisdaël - I am really loving the new tab option, but I am looking for a way to add a panel above the tabs so that it is available no matter which tab the user is on. If I add the panel directly to $panels, it always appears at the bottom of the page below the tabs. Any ideas how I can make this work? Thanks so much!1 point
-
Hi @d'Hinnisdaël - I wonder if you'd be willing to support loading a tab directly from the hash in the URL please? Thanks for considering.1 point
