All Activity
- Today
-
ryan started following Weekly update – 26 December 2025
-
I hope that you all had a nice winter holiday (Christmas, etc.) or are still on holiday till the new year. Not a lot to report this week since I’ve been on holiday too, but we finally launched that site that’s been keeping me busy for the last few weeks, so I’ll hopefully be spending a lot more time in the core this coming week. I'll get the site posted to the sites directory once some more of the post-launch details are taken care of. One thing I learned in launching that site is that Markup File Regions work great during development, but not so great on a busy site (at least a site using Amazon’s EFS file system, which is very slow). I ran into all sorts of strange issues so ended up converting the file regions back to regular old static CSS and JS files, and then everything ran smoothly again. So as solid as the file regions are during development, they will need more work before I use or recommend them in production. That’s the way it goes with developing new stuff sometimes. There is however a pretty nice improvement to Markup Regions committed this week though. Prior there were some limitations as to what could populate what. Typically output before the <html> (i.e. from template files) populated into output that comes after the <html> (i.e. a _main.php file). But now it is possible for the population of content to go in either direction. Further, more nested elements can also populate less nested (or non-nested) elements. It’s a little hard to explain, but basically, you don’t have to think too much about when and where you can populate things as Markup Regions will figure it out in the final output. This makes it even easier to use and hopefully more foolproof than before. Thanks for reading and have a great weekend!
-
- 5
-
- Last week
-
Not sure who would be the best person to reach out for help on this but there's a critical update for my module, Fluency, and getting the word out is not possible because the thread is locked and hidden from everyone but me. I edited my original post last week (IIRC), which I've done before, and I didn't know that this hid it, which hasn't happened before. This is a bit odd given how old my forum account is and reputation 🤔 I'm attempting to let all Fluency module users know that there is a critical update that must be installed for all users that are using DeepL as their translation service or all translation services will fail with an error. This is due to a short-notice breaking change by DeepL stating that they're deprecating their previously documented authentication method on January 15th, 2026. If you're reading this and use Fluency, please update your module installs to version 2.2.0 which now available via a ProcessWire admin module upgrade, the modules directory, Github, and Composer. I pushed the update as soon as I could to give ProcessWire devs as much time as possible to update their installs and those of their clients. Thanks to whomever sees and can/does unlock the thread!
-
- 4
-
-
The problem with all paid modules kongondo used to sell is that there is no documentation. My (paid) copy of MediaManager never worked properly (the same is true for Padloper 2) and there is no support at all, so I really try to avoid anything that comes from him...
-
Hi @teppo This module is wonderful. I wonder is it possible to change the data stored in the database? If possible, is there a hookable method I can use to edit the data? Thanks. Gideon
-
Hello all! There's a new version of Fluency and a critical update announcement for all DeepL users. Fluency 2.2.0 has just been released and is a critical update for all users of Fluency that employ DeepL as their translation service. As mentioned above, DeepL is deprecating their previous method of API authentication on January 15, 2025. This means that all Fluency versions less than 2.2.0 that are using DeepL will no longer translate content. Upgrading from Fluency 1.8.0 or earlier requires a complete uninstall/reinstall. The module will have to be configured again, so note your API key if you don't have access to it otherwise. This will not result in any content loss. Fluency 2.2.0 also brings additional features and bugfixes. These include compatibility with AdminThemUikit v3 and its theming customization abilities. Fluency also now uses CSS custom properties so it is possible to customize it separately. This release also includes a fix for an issue that may affect saving content in RockPageBuilder fields mentioned earlier in this thread. For full notes on changes and improvements see the Github release page. If you have any trouble with the module please report them here, filing an issue on Github is helpful as well. Thank you all for your feedback and ongoing support. Additional thanks to the developers who have donated via PayPal, always appreciated!
- 305 replies
-
- 3
-
-
- translation
- language
-
(and 1 more)
Tagged with:
-
I suck when it comes to designs, I am going to explore this and update, thanks so much because I code more than I design so you saying it's good has made my day.
-
wbmnfktr started following My Personal website
-
I love these clean minimal styles. Have you tried to add some nice monospace font? Could make a nice contrast in some places.
-
As usual this has been my ritual for years, changing my website and it's always been Processwire as usual, this time I went for a minimal look.
-
WireWall - Advanced Security Firewall Module
Stefanowitsch replied to maximus's topic in Modules/Plugins
The custom AJAX endpoints that RockFrontend is using are basically PHP files located in: /site/templates/ajax/ So the requests go to: http://www.mysite.com/ajax/myEndpoint To prevent these requests from being blocked I tweaked this piece of module code: // WireWall.module.php line 1140 // Check if request URL contains /processwire/ or /admin/ or /ajax/ $requestUri = $_SERVER['REQUEST_URI'] ?? ''; if (stripos($requestUri, '/processwire/') !== false || stripos($requestUri, '/admin/') !== false || stripos($requestUri, '/ajax/') !== false) { return true; } -
@Robin S That looks great, thanks! Will take that as a starting point and see where it takes me. Probably make this configurable behind a proper inputfield setting.
- 6 replies
-
- inputfield
- checkboxes
-
(and 2 more)
Tagged with:
-
Another one is Cockpit Headless CMS nice and light...
-
Also you can check out Sulu CMS based on Symfony Framework, Here is a skeleton project its like ProcessWire profile. its supports live-editing, block field [free] (its like repeater matrix), form-bundle [free] (like form builder), content-types, multil-language, multi-site, multi-database..... You can set content types from xml config file, located at config/templates You can set multi-domain and domain languages from xml config file, located at config/webspaces also it has snippet support... You can check the demo
-
[WIP/Proposal] Wire2Pdf – A PHP 8 compatible fork of Pages2Pdf
ukyo replied to markus-th's topic in Module/Plugin Development
I see :(, fork and update old module look like best solution for Pages2Pdf module users -
@ukyo Thanks for the suggestion! I considered that approach, but there is a significant technical blocker: Class Name Collision. The legacy Pages2Pdf module already defines a global class named WirePDF internally. The module you referenced also uses the global class WirePDF. If I were to build a wrapper or if a user tries to migrate from the old module to the new one, PHP would throw a Fatal Error: Cannot redeclare class WirePDF immediately if both files happen to be loaded (which can happen easily during uninstall/install processes or if site caches aren't perfectly cleared). My goal with Wire2Pdf is to cleanly separate the logic using Namespaces (e.g., ProcessWire\Wire2Pdf). This ensures: Zero conflicts: It can theoretically exist alongside the old module during migration/testing without crashing the site. Full Control: I can ensure the mPDF library is updated and configured specifically for ProcessWire's needs without depending on a third-party wrapper that relies on global class names. So, while extending would be "dryer", a fresh, namespaced module is the safer and more robust path forward.
-
Maybe I have a few little goodies that you might like 😉 Wire2PDF (first Alpha) What's new? Custom fonts You can upload and use own fonts Set PDF metadata (defined with variables or custom by a specific templatefield title, subject, keywords, author and creator Create PDF/A-1b for font embedding Now i have to test before it is ready to publish.
-
[WIP/Proposal] Wire2Pdf – A PHP 8 compatible fork of Pages2Pdf
ukyo replied to markus-th's topic in Module/Plugin Development
@markus-th @Klenkes If you're looking to update Pages2Pdf, I recommend creating a new module with the same name but extending WirePDF instead. It’s a much more efficient way to modernize the module without reinventing the wheel. <?php namespace ProcessWire; // Instead of a full rewrite, just extend the new module class Pages2Pdf extends WirePDF { public static function getModuleInfo() { return [ 'title' => 'Pages2Pdf extends WirePDF', 'version' => '1.0.0', 'requires' => 'WirePDF' ]; } } Tip: You can use WirePDF for all new projects. To support older projects without a full rewrite, simply create a Pages2Pdf wrapper that extends WirePDF. This way, you stay up to date with the latest PDF engine improvements while keeping your existing codebase intact. -
Klenkes started following [WIP/Proposal] Wire2Pdf – A PHP 8 compatible fork of Pages2Pdf
-
Thanks for sharing. I’ve actually looked into that repository. The main issue I see is that it uses the class name WirePDF, which causes a naming collision because the original Pages2Pdf module already defines/uses a WirePDF class internally. This makes migration difficult and would crash the site if both are present. My goal with Wire2Pdf is to use proper Namespaces (e.g. ProcessWire\Wire2Pdf) to ensure PHP 8 compatibility without risking these kinds of class name conflicts.
-
WireNPS is a comprehensive module for collecting and analyzing customer feedback via a modern Net Promoter Score (NPS) popup interface. Key Features: Elegant NPS Widget: A non-intrusive, mobile-friendly popup for ratings (0-10) and text feedback. Real-time Analytics: Dashboard featuring NPS score calculation, score distribution charts, and 30-day trend graphs. Multilingual Support: Built-in support for English, German, French, and Chinese with automatic browser/user language detection. Flexible Access: Support for both logged-in users and guests (Public/Private modes). Data Export: CSV export functionality for external analysis. Privacy Control: Configurable IP/User Agent tracking and cookie management. Requirements: ProcessWire 3.0+ PHP 8.2+ Quick Installation: Download or git clone into /site/modules/WireNPS/. Install via the ProcessWire admin. Create an AJAX handler page using the provided template. GitHub: https://github.com/mxmsmnv/WireNPS
-
- 6
-
-
-
A quick WireIconifyData class or your name it as IconifyWireData, IconifyValue <?php namespace ProcessWire; class WireIconifyData extends WireData { public function __construct(?array $data = null) { parent::__construct(); // set defaults if (!is_array($data)) { $data = [ 'raw' => null, 'set' => null, 'name' => null, 'path' => null, 'url' => null, 'svg' => null, ]; } $this->setArray($data); } public function __invoke(array $attrs = [], bool $withHeader = false) { return $this->render($attrs, $withHeader); } public function render(array $attrs = [], bool $withHeader = false): string { if (!$this->get('svg')) { return ''; } try { $xml = new \SimpleXMLElement($this->get('svg')); foreach ($attrs as $key => $value) { if (isset($xml->attributes()->{$key})) { $xml->attributes()->{$key} = $value; } else { $xml->addAttribute($key, $value); } } // Return XML without the header declaration for clean HTML embedding $out = $xml->asXML(); return $withHeader ? $out : preg_replace('/^<\?xml[^?]*\?>/i', '', $out); } catch (\Exception $e) { wireLog('error', "SVG icon: {$this->get('name')} error => {$e->getMessage()}"); return ''; } } public function __toString(): string { return $this->render(); } } Usage: <?php // render echo $page->icon_field; // render with attrs echo $page->icon_field->render( attrs: ['width' => 40, 'style' => 'color: red;'] ); // render with attrs and header echo $page->icon_field( attrs: ['width' => 40, 'style' => 'color: red;'], withHeader: true );
-
Thanks @ukyo. I'm now thinking that the module itself should remove the XML declaration when setting the svg property in the formatted value, seeing as the most likely use would be for inline SVG. Do you agree? If so I'll release an update.