Leaderboard

I hope you are having a great week. Today I've released new versions of two ProcessWire ProFields modules: Table and Combo. In addition to various minor improvements and fixes, the biggest update in both is the addition of file and image fields. Since this is a fairly major feature addition for both modules, please consider these versions in a beta test stage for the moment. Both are available for download in the ProFields board now. Table v23 In ProFields Table both "file" and "image" column types were added. These are fairly basic file upload fields, but a major improvement over not having them at all. It can hold one file per column per row in the table. You can have as many file columns as you need per row. The front-end value of your file or image columns is one you are likely used to using already: Pagefile or Pageimage objects, just like they would be in a regular single-file or image field. This means your file/image values in your Table rows can benefit from many of the built-in methods you already use, such as the ability to present resized images, WebP variations, etc. When you configure a file column you can specify what extensions you want to allow and the maximum number of bytes you are willing for it to accept in an upload. When configuring an image column, you also gain settings to specify the thumbnail image preview size in both regular and HiDPI resolution. Combo v9 The update for Combo fields was similar to the Table field except that file and image fields go quite a bit further in Combo than they could in Table. Specifically, you get almost the full set of InputfieldFile/InputfieldImage configuration settings and features, including the ability to support both single and multi-file uploads, image actions, variations, focus control, description input, tags input and more. The only things missing relative to a regular File/Image field are the manual Crop action (Image field) and the ability to manage separate custom fields for each file or image. The front-end value for your Combo file fields is identical to what it would be on a regular ProcessWire File or Image field. Specifically a Pagefiles or Pageimages (plural) object if supporting multiple files, or a Pagefile or Pageimage (singular) object if supporting 1 file. To say it another way, you can use this exactly as you use other dedicated file/image fields in ProcessWire. Not yet included is the ability to query the properties of a file/image field from selectors, like when using $pages->find(). I'm still working on that part, but since I know most probably don't need that I decided to get this version out first and then continue working on that part. Core updates The core updates this week were mostly minor, even if there were a lot of them. One of the ways that I stay up-to-speed on all the core code is to regularly read through all of it and make small adjustments along the way... anything that makes the code easier to read, or easier for PhpStorm to inspect it. You've seen these kinds of updates pretty much every week for years, but I hadn't thought to mention it before. This week there were more of these kinds of updates than usual so I just wanted to mention that what it's for. What sometimes looks like micro-optimization or minor code changes is usually just me staying fresh and up-to-date with the core. ? That's all for this week. I hope you have a great weekend!

Check this one out: Processwire on the web with wirekit - - - https://bestofphp.com/repo/kreativan-wirekit-core https://github.com/kreativan/wirekit-core https://start.wirekit.dev/core/wirekit/ui/

Huge update to save us all time. I would buy you a beer (if you drink alcohol) every Friday if I could.

I just stumbled upon this pretty recent article by Ionos, one of the biggest hosting providers in Germany (formerly 1&1, not sure how big they are elsewhere): https://www.ionos.com/digitalguide/hosting/cms/processwire/ It’s in english and includes a comparison to Wordpress (the tabular comparison is kind of broken, though).

The module provides a list of PageTable based content elements. It enables the backend user to easily create, publish, move, delete, copy and paste content elements. The rendering logic of the module is detached from the ProcessWire backend scope via Shadow DOM and allows the elements rendering identical to the front end. It ships with some helper functions that simplify the handling of content elements. Download/Install Github: https://github.com/neuerituale/PageTableNext Module directory: https://processwire.com/modules/page-table-next/ Composer: composer require nr/pagetablenext

Also available in german ?https://www.ionos.de/digitalguide/hosting/cms/processwire/

What the error you posted says is basically that your code doesn't found a page matching the path you've provided. This is why it returns a NullPage object, which is kind of like saying "sorry, didn't find anything, here's a placeholder object for you instead". And since you can't remove a NullPage, that explains the error you saw. Now, what you're describing here sounds like some kind of a bug, though it's a hard to pinpoint exactly without access to the code, site, and/or database. Couple of suggestions: When this happens, I would first check if logging out and then in again removes that "page" from the menu. Admin menu is cached independently, so this could be the reason. Though I'm not sure why said cache wouldn't reset automatically. If that doesn't help and there is indeed an actual page there, it would be interesting to know what kind of data it has in the "pages" table in the database. Another reason why this might happen would be if a page is somehow corrupted. A typical signal of that would be that it exists in the database, but has a strange value in the "status" column. If you post your current code, I would be happy to take a closer look (at some point) in case there's some sort of issue there ?

I did something similar in a project, using this library: https://github.com/Rct567/DomQuery to manipulate the content of the SVG file (it's basically XML), using file_get_contents (from file), and then modifying texts, assigning/removing css classes, hiding/removing elements, etc. In this particular case, I ended rendering the modified SVG to PNG using Imagick for the final output (delivered by AJAX). The SVG document must be prepared in advance for that. Using the proper IDs and classes. Visual styles were applied by CSS classes and not directly on elements, in order to manipulate them. Modifications were not interactive, they were captured with a form.

Interesting problem. If I understand correctly, you want to have two sources of truth that you need to connect somehow, i.e. the data inside the SVG and data from ProcessWire? I wonder if that’s worthwhile, because what are the chances you’ll want to change something on one side and not the other? To get translatable strings inside the SVG you could always use {placeholders} and populate them with WireTextTools, but as soon as you significantly change a text’s length, you’ll need to touch the SVG anyway, plus you will need to keep the placeholder names in sync. Obviously authoring the SVG is the most annoying part of managing this content, but I don’t see how you would get around it, so maybe try and make it the only part? You could cram everything into the SVG in some standardized way, like predefined classes and data- attributes, then analyze it with JS and build all the toggles dynamically.

Just a quick note, if you're on Linux & Code-OSS and have trouble opening your ALFRED / Tracy links to directly edit template code (around 34:00 in the video), you need to create a separate URL handler for vscode:// type links in ~/.local/share/applications create a file code-oss-vscode-url-handler.desktop #!/usr/bin/env xdg-open [Desktop Entry] Name=Code - OSS - VSCode URL Handler Comment=Handles opening of vscode:// URLs in Code-OSS GenericName=Text Editor Exec=/usr/bin/code-oss --open-url %U Icon=code-oss Type=Application NoDisplay=true StartupNotify=true StartupWMClass=Code - OSS Categories=Utility;TextEditor;Development;IDE; MimeType=x-scheme-handler/vscode Keywords=vscode; Terminal=false Borrowed from here: https://github.com/Microsoft/vscode/issues/48528#issuecomment-414056547 And Alfred is your new best pal ?

The problem here is that $pages->get() can return either a Page or a NullPage. NullPage is a null object that (in terms of API usage) behaves like a Page, but doesn't have any content, and doesn't actually match any page on the system. Thus you can't delete a NullPage. NullPage doesn't have an ID, so here's one way you can solve this, checking for an object with an ID: public function ___uninstall() { // ... $dashboard = wire('pages')->get('/admin/kiosk_dashboard/'); if($dashboard->id){ $dashboard->delete(); } // ... } Edit: just for the record, admin pages can be renamed or moved, so keep in mind that at least technically your uninstall routine may leave "orphaned" pages behind. In case your dashboard page uses your Process module as it's process, here's what you could do instead of relying on the path/name always being /admin/kiosk_dashboard/: public function ___uninstall() { // ... $module_id = wire('modules')->getModuleID($this); $dashboard = wire('pages')->get('template=admin, process=' . $module_id); if($dashboard->id){ $dashboard->delete(); } // ... }

v0.2.0 of the module is released, which is a fairly major update that brings support for Repeater, FieldsetPage and Repeater Matrix fields. Using the "Field widths" field you can quickly set the width of inputfields within a Repeater/FieldsetPage field or within each Repeater Matrix type. Repeater: Repeater Matrix: