Leaderboard

ProcessWire 3.0.169 contains 19 commits relative to 3.0.168, and most are focused on improvements and minor fixes throughout the core. For more details see the dev branch commit log. This week I’ve also been working quite a bit on a new ProFields module that at the moment is called Combo. It contains both Fieldtype and Inputfield modules within it, and I’ll have more to tell you about it soon. But I can say that it fits right in with the purpose of ProFields, which is: greatly reduce the number of fields needed to accomplish a particular need. And it does so in a way that isn’t easily achieved with any other module at present, so I think it’ll be a nice addition. The Inputfield part of it can also be used independently of the Fieldtype, meaning you could use it in FormBuilder forms, etc. I’ve got to keep it short today because of the Thanksgiving holidays here in the US (my wife is off work and kids have no classes today). Thanks for reading and have a great weekend!

Just a quick heads-up: https://www.php.net/releases/8.0/en.php. PHP 8.0 is out. Some pretty fancy new features there, really looking forward to getting my hands on this one ? Might be a good idea to test before updating any critical environment, though. As always there are some backwards incompatible changes etc.

This site has been a long time in the making. Back story: Was first developed in PW 2.something many years ago. Around 5yrs ago, it underwent a major upgrade. The look was very 90's and the booking page had around 50 input fields on the one page. See screenshots. Original dev, who did a great job with web technology at the time, went AWOL Business was sold to a new owner New owner engaged me to revamp the site. I laugh & laugh & laugh. If only I knew then what I know now! It was crucial that the years of historical data be kept and accessible Busy period is November to February (Aussie summer). And then came COVID. Victoria was the state hardest hit with C19 in Australia and lockdowns were harsh. Definitely no parties. The possible product configurations, hire rates & rules (all with 'except for this one') had me melt into a puddle at times. Pricing is shown on product pages only when a valid venue postcode & event date entered and can change depending on the surface type (eg concrete attracts a $50 surcharge) One of the biggest things that tripped me up was the previous dev combined data/module logic with presentation HTML. I had to rewrite all the old code to adapt to the new layout. Would have been much easier to have logic & presentation separated. A while ago I chose to stop using CSS frameworks to dig deep into how CSS really works. Much of what I have learnt is in the site frontend code. The site is fully responsive and the only JS used is on the View Booking page when a customer alters the booking item qty. There is NO frontend presentation JS, including the dropdown & mobile menus. Where it stands today: There are still some things to do, including implementing a very sensible change recommended by @ryan. In addition to the frontend, there are a number of new backend/admin reports Victoria is coming out of C19 hell and getting back to normal The site is live and online bookings are rolling in New modules added: ProCache FormBuilder + StripePayment + Page Break CampaignMonitorAPI ProFields - Functional Fields ProFields - Repeater Matrix RockMarkup2 Database Backups Upgrades SeoMaestro TracyDebugger Page View Statistic Big shout out 'Thank you' to all the PW devs who responded when I reached out for help in the forum. Check out the new look www.aaronsamusements.com.au

$country = $session?->user?->getAddress()?->country; love it ?

Yes, Yes and ?‍♂️ It should be a good task candidate for the following. ? Give a try to the modules developed by @mtwebit DataSet and Tasker Configure it and let the thing running the night or a good nap. A preview :

My apologies, you were also right @Zeka ! As the parent_id does not persist after ___renderAddable, I'm adding the same hook for both functions in my ready.php : $wire->addHookBefore('InputfieldPage::renderAddable', null, "changeParentId"); $wire->addHookBefore('InputfieldPage::processInputAddPages', null, "changeParentId"); function changeParentId($event) { $inputfieldPage = $event->object; $page = $inputfieldPage->hasPage; if($inputfieldPage->hasField == "subcategories") { if ($page->category) { $inputfieldPage->set("parent_id", $page->category->id); } } } And it works great ! Thank you !

https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldPage/InputfieldPage.module#L841

This thread/post might also be interesting for you:

A little more to the back story... Client's biggest target audience is children's parties hence the look. The only time I said an absolute "NO" to client was when client said use "Comic Sans" font. There are some boundaries I will not overstep! Heading font is Google 'Happy Monkey'. ?

Actually, even this works: $page->getField('first_name')->columnWidth

Besides @adrian's suggestion, here is another way: $width = $page->fields->getField('myfield', true)->columnWidth;

Ryan's ProCache module is the other obvious candidate to mention here.

That's basically impossible for anyone to answer as there are so many other variables involved than just the row count and your machine specs. It will also depend on how much of that data needs to be loaded per page view, how many requests per second you expect to handle, will you be using caching, are there background updates happening, are the tables correctly indexed and using the most suitable storage engine, how many sessions will be active at peak, will you be triggering external API calls as part of the page views, what about asset loading - all assets optimised, and how often you'll need to be updating rows in the DB, do the pages involve JS rendering anything on the frontend etc. etc. I think you'd be better off setting a target for acceptable page loading times and then asking "What do I need to do to get 80% of my page loads to this time or better?" You also need to consider if PW's API is a good fit for your programming needs and if the Admin interface is suitable for you and any users who may need access to the admin. I'd suggest setting your speed goals and then trying an import of a subset of your data and then seeing how your resource needs and page speeds scale going from say 100 thousand to 200 thousand rows and then extrapolating from that. If you do try out PW, please keep us updated with your results.

Hi @The G, thanks for noticing this behavior! During the development of PrivacyWire I never thought of showing or hiding divs or "regular" elements - only thought of scripts, videos, media ... So, good catch! I refactored that part of the priw_updateAllowedElement function to fix this bug. Cloning is required for everything, where media, scripts or other external stuff gets loaded... Waaaait a minute... While I was writing these lines of nonesense, I realized that this idea is wrong! ? You're right - keeping the elements alive and just update the attributes works for scripts, images, iframes and of course divs and other elements, too. I refactored again and tested the new version with all kind of elements and media... Only script tags need to be a new added element, as they will not run otherwise: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model 0.4.2 fixed it!

Admin Theme Canvas DEPRECATED: I am no longer supporting AdminThemeCanvas. Now that the new native KONKAT theme is part of the ProcessWire core, this module is largely redundant. Thanks to everyone who used and supported it!. This repository will remain available for legacy projects but will not receive further updates. To make the KONKAT theme behave more like this one you can install the AdminQuickTree module, which gives you direct access to the page tree navigation. A minimal admin theme with optimised page editor UI, based on Uikit 3. Currently this is close to stable, but users are advised to be cautious and test thoroughly. This theme is tested in all major Browsers including IE 11, Edge (>85), Chrome (>85), Firefox (>81), Safari (>11). If you find any bugs or have ideas for improvements, feel free to post your feedback. Download from Github Download from Modules Page Features Minimal black and white admin theme Fixed masthead navigation Direct access to page tree navigation inside page dropdown Less distraction for editors (when editing a page, the tabs are displayed as a dropdown menu inside the main navigation) Options to customise the ui Less distraction for editors Direct access to page tree navigation inside dropdown Page tree Options to customise the ui Login (inspired by AdminThemeBoss) Requirements Process Wire 3.0.100 or greater Installation Go to “Modules > Site > Add New“ Paste the Module Class Name “AdminThemeCanvas“ into the field “Add Module From Directory“ Click “Download And Install“ On the overview, click “Download And Install“ again… On the following screen, click “Install Now“ Go to your user profile page and change the theme to Admin Theme Canvas

As we often use Matomo (former known as Piwik) instead of Google Analytics we wanted to embed Matomo not only in the template code but also via the ProcessWire backend. That's why I developed a tiny module for the implementation. The module provides the possibility to connect to an existing Matomo installation with the classical site tracking and also via the Matomo Tag Manager. If you have also PrivacyWire installed, you can tell MatomoWire to only load the script, if the user has accepted cookies via PrivacyWire. To offer an Opt-Out solution you can choose between the simple Opt-Out iFrame, delivered by your Matomo installation, or a button to choose cookies via PrivacyWire. You'll find the module both in the module directory and via github: ProcessWire Module Directory MatomoWire @ GitHub MatomoWire @ Packagist ->installable via composer require blauequelle/matomowire I'm looking forward to hear your feedback!

emplate Field Widths Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template. Since v0.2.0 the module also adds a similar field to the settings of Edit Field for Repeater, FieldsetPage and Repeater Matrix allowing you to quickly set the widths of inputfields within the Repeater/FieldsetPage field, or within each Repeater Matrix type. Note: widths are only saved if the edit form is submitted with the "Field widths" field in an open (non-collapsed) state. Edit template Edit Field: Repeater Edit Field: Repeater Matrix Why? When setting up a new template/repeater or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process. Config options You can set the default presentation of the "Field widths" field to collapsed or open. Widths entered into the "Field widths" field are only applied if the edit form is submitted with the field in an open (non-collapsed) state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width. https://github.com/Toutouwai/TemplateFieldWidths https://modules.processwire.com/modules/template-field-widths/

Single Site, Developer and Agency Licenses are available via our LemonSqueezy Store >>> Please get in contact after purchasing, citing your license key & forum username, so we can add you to our support area. <<< This is a module pack by Nifty Solutions for Processwire CMF/CMS version 3.0.149 or later (running on PHP 7.2+) that extends the core features for password recovery making them more flexible and easy to use. Features Can send just the verification code in emails (removing the clickable link), and immediately show the reset verification page. This forces the reset to be completed in the same session it was started from. Allow the password reset to be initiated in one session and completed in another. You no longer have to complete the reset from the same browser and tab. There are options to allow you to still require reset completion from the same IP address. Prevention of incorrect data entry in the reset initiation step, users are warned if they enter an email in a username field. Optional customisation of the verification code. Can make manual and/or mouse-based copy-and-paste from the email easier. Optional auto-completion of the verification code field in the password reset step. This makes things easier for users as they don't have to copy-and-paste from their email client. Be warned, however, that this can facilitate automated reset attempts. Control how long reset links are valid for (sometimes an hour is much too long) and update the text of outgoing emails and reset screens to report the new value. Optionally allowing automatic user login following a successful password reset. This is not recommended but is supported. This option is never available to Superusers or users with 2-factor authentication requirements on their accounts. You can additionally limit this to users with specific roles. Allows the reset process to require input of the user's Time-based one-time (TOTP) value - if they have TOTP setup on their account. You can also mandate the entry of a valid TOTP in order to complete a password reset. The TOTP field extends ProcessForgotPassword and operates with or without NiftyPasswordsPlus. Works by extending the core ProcessForgotPassword module so it works on the Admin login page and your custom LoginRegisterPro pages. You'll also get access to NiftyHashedTokens in your template and module files - a HMAC-Hashed key-to-value store, providing tamper-detection of the key and controlling how many times it may be accessed in a given period along with IP address checking. Pre-Requisites This requires PHP7.2 or better and a recent copy of Processwire with the ProcessForgotPassword and InputfieldSelect modules installed. Installation After purchase you will have access to the latest version of the pack as a single zip file.If this is your first Nifty installation: simply unzip the file in a temporary location and transfer the resulting Nifty folder into the site/modules directory of your site. Then refresh the modules in Processwire and install the NiftyPasswordsPlus module.If you already have other Nifty products installed: unzip the file in a temporary location and look in the Nifty folder you unpacked. Copy any new subdirectories from there into your existing site/modules/Nifty directory. Log in to Processwire, refresh your modules and install NiftyPasswordsPlus. You will need to acknowledge the disclaimer, enabling the module in order to proceed. Refunds We offer a no-questions-asked refund policy in the first 14 days from the date and time of your purchase. Settings Step 1: Step 2: Gives options changing how the reset link works. Verification code customisation options: This can lead to much simpler codes in the reset emails... Step 3: If you install FieldtypeUserTOTPValue as well, you also have additional options to require TOTP 2FA for reset. Step 4: Additional settings: FieldtypeUserTOTPValue allows you to add TOTP as a confirm field in ProcessForgotPassword: Which then requires the user doing the reset to enter their TOTP 2FA code (if set on their account) in order to reset their password: If the user does not have TOTP set up on their account, they just leave this blank. If they do have TOTP set up, they need to enter the current value. If you are using this along with NiftyPasswordsPlus, then you can additionally enforce role-based requirements for entry of a correct TOTP value in order for password reset to work. It does this by hooking FieldtypeUserTOTPValue's RequireTfa() method. You can do the same from your site/ready.php file to add any additional checks you'd like for your particular site. We currently only support TOTP 2FA as it is simple, avoids sending another email (in case email is compromised) and the bar to user adoption is quite low. Finally, we have NiftyHashedTokens: Single Site, Developer and Agency Licenses are available via our LemonSqueezy Store >>> Please get in contact after purchasing, citing your license key & forum username, so we can add you to our support area. <<<

Hi Robin, Thank you very much. Works perfectly! My forum search didn't result in that post unfortunately. With regards, Reems

@rjgamer Fix pushed, you can update the module from Github, master branch or wait that the modules directory update itself to update it from ProcessWire Upgrades (I can't login to do it manually). Please let me know ??

It does.

Hi @humanafterall. Have you read this information https://processwire.com/docs/more/multi-site-support/? By the way, you can use urlSegments to output low-bandwidth version of the pages. For example site.com/some-page/low/ where site.com/some-page/ is normal page and site.com/some-page/low/ is low-bandwidth. It's just an idea, but I think that this one is easier to implement and support.

Duplicator does not work with PHP 8 anymore. get_magic_quotes_gpc() is removed. Is there any Roadmap to see how the module get evolved in the next few months?

@benbyf I think that's not possible out of the box with the module. If you really want to use one api key per user you somehow would need to programmatically create them and store a reference on the user. But honestly this doesn't look like a good solution to me. You're free to add any checks in your API functions to restrict certain user/roles from doing things, and that is probably how I would handle this. This way you can leverage the entire ProcessWire API. For example: // Route: /api/publish-page/{id} public static function publishPage($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']); $page = wire('pages')->get($data->id); if(!wire('user')->hasPermission('page-publish', $page)) { throw new Exception('Not-allowed'); // Or use AppApiException here } // Publish page }

@FireWire Thank you for the page-edit-fix, this was one of the most important things to make this module usable in real! From our point of view, a separate translation permission would make perfect sense, because not everyone, who can edit a page, should do translations. Mainly because the service is subject to a charge, one should be sensitive when giving the translation service permission. Best regards, Thomas.

@Motion Expert - this value is not stored by this module, but rather by PW in general. You can get the width of a field in the content of a particular fieldgroup (basically the same as a template) like this: In my example, I have the width of the first_name field set to 50% for the user template/fieldgroup.

One other suggestion: if any PW selectors turn out to be slow across so many records, try using the RockFinder3 module (https://github.com/baumrock/rockfinder3).

You can do this through a CLI script boostraping ProcessWire. It should be possible, I've imported millions of rows from a CSV using very little memory, although taking quite a bit of time. I'd recommend also using database transactions for saving batches of new pages.

I was mentioned in this post by @MoritzLost and thought that would be a nice challenge and a nice little tutorial. I've updated the docs: https://github.com/baumrock/rockfinder3#example-group-by-date Example: Group by date As an example we will create a list of the count of cats and dogs related to their page-creation day. We start with a simple list of all ids of cats and dogs: $rf = $rockfinder->find("template=cat|dog"); $rf->dumpSQL(); $rf->dump(); We can't simply add the created column because this is a timestamp. We need a formatted date, so we add it as custom SQL: $rf = $rockfinder->find("template=cat|dog"); $rf->query->select("DATE_FORMAT(pages.created, '%Y-%m-%d') as created"); $rf->dumpSQL(); $rf->dump(); Great! Now we need to group the result by the date string: $rf = $rockfinder->find("template=cat|dog"); $rf->query->select("DATE_FORMAT(pages.created, '%Y-%m-%d') as created"); $rf->query->select("COUNT(id) as cnt"); $rf->query->groupby("DATE_FORMAT(pages.created, '%Y-%m-%d')"); $rf->dumpSQL(); $rf->dump(); Wait... That's not what we expected, right? That's because we still have the pages.id column in our SELECT and GROUP BY statement and therefore we end up with all the cats and dogs as unique rows. To get rid of that column we make one important change: Instead of adding the SELECT and GROUP BY statement to the query we overwrite it: $rf = $rockfinder->find("template=cat|dog"); $rf->query->set('select', [ "DATE_FORMAT(pages.created, '%Y-%m-%d') as created", "COUNT(id) as cnt", ]); $rf->query->set('groupby', [ "DATE_FORMAT(pages.created, '%Y-%m-%d')", ]); $rf->dumpSQL(); $rf->dump(); Not too complicated, right? You want yearly stats? Easy! Simply change the date format string to %Y:

You'll need to use a hook for this rather than the access settings in the template. Give the role view and edit access in the template settings and add the following in /site/init.php $wire->addHookAfter('Page::viewable, Page::editable', function(HookEvent $event) { $page = $event->object; $user = $event->wire()->user; // Only for non-superusers, for a specific template if($user->isSuperuser() || $page->template != 'restrict_files') return; // Adjust to suit your template name // User may only view or edit page if they created it $event->return = $page->created_users_id === $user->id; });

Great, didn't know limit=0 would work, good to know! You don't need the second row, just a less verbose and error-prone alternative to the procedural code in your initial post ? I prefer this functional style, but in the end, it doesn't even matter.

Are you talking about adding the script in the PW backend or frontend? If backend, then it's simple: // in your init() method of the module $url = $this->wire->config->urls($this); // url to current module $this->wire->config->scripts->add($url."YourScript.js"); You can hook ProcessPageView::pageNotFound and define custom endpoints so you don't need to create a file for the ajax endpoint manually. A simple example can look like this: public function init() { $this->addHookBefore('ProcessPageView::pageNotFound', $this, 'handleWebhooks'); } public function handleWebhooks($event) { $url = trim($event->arguments(1),"/"); switch($url) { case "api-create-user": $this->createUser(); break; case "api-delete-user": $this->deleteUser(); break; // by default we exit early and don't do anything default: return; } // show 200 status code instead of 404 // this could also be done in the method calls above http_response_code(200); die("success"); } There's also this thread with lots of infos:

Hi all, After seing the website featured in the latest Processwire weekly (thank you @teppo !!), I thought it could be nice to post some details here. I have actually made a few websites using Processwire, but it's the first time I'm posting one in the showcase. Backstory I made a first version of this website in end-2017 when I was starting to use Processwire after a friend recommended it to me. I was in charge of the front/back-end, and helped a bit on the design. At the time there was a slideshow of featured projects as the homepage, the project page was the only template with content blocks, and the information pages (about / contact) were specific templates. About the content blocks, I didn't know about the Repeater Matrix module so I kinda implemented my own, having a simple Repeater with a Select Options field defining which fields to display. All in all the website was pretty nice when it came out and I learned a lot in the process, but this year the agency wanted an update to fit their new narrative, so it was a nice opportunity to make some due changes. Back-end Modules I used : Repeater Matrix ProCache Seo Maestro Email Obfuscation Inputfield Chosen Select Color Minimal Fieldset Page Field Edit Links Runtime Only Tracy Debugger (of course!) This new version is all about content flexibility. The information pages now all share the same template, allowing them to create as many as they want. Each visible templates ("home" / "page" / "project") contains a Repeater Matrix field for content blocks, with 15 different types to choose from and options to add variations in the layout. Front-end To answer to the PW Weekly : it is indeed all custom-made except for three external libraries : plyrjs, flickity and lottiejs. I really like sveltejs but I still have to figure out how I could mix it with PW in my process. The animation in the introduction is described by a .json file and displayed as a SVG using Lottie. The transition colors can be changed. The menu order is defined by the manual sorting in the admin... I don't really know what to say here since it's all hand-made, let me know if you have any question! Screenshots Thanks !

If it's not a matter of life or death, I sometimes just leave the page hidden instead of unpublished for a short while... hidden is viewable with the link but it shouldn't show up in the nav, etc.

I've run into this problem on a client site before. I was never able to duplicate it myself, but noticed there were style attributes ending up in the CKE field of my client's site somehow, and the client said they pasted from Word. I don't have Word, and I'm not observing the issue occurring with pasting from anything else, so there must be some Microsoft trickery going on, who knows. I don't understand why CKE's ACF allows it. It does seem like a CKE bug. I'm sure it's possible to configure HTML Purifier to remove that stuff, but haven't looked too closely into it. While there is a way to force CKE to paste as plain text (see thread that flydev linked), I don't really like losing links and normal CKE formatting when I paste, because I'm often pasting from one CKE field to another, and having to redo all the formatting is a pain. Usually if I want to paste as plain text, I just use SHIFT-CMD-V on Mac (SHIFT-CTRL-V on PC), as this is a pretty universal way to paste as plain text, anywhere. But the reality is, clients aren't likely to remember it, and many are doing Edit > Paste, rather than using the keyboard. I'd rather not have the client have to think about whether they need to use plain text pasting or not. A simple way to remove style attributes from CKE fields is to hook after the process input, look for them, and then remove them. This hook at the top of your /site/templates/admin.php file should do the trick: $wire->addHookAfter('InputfieldCKEditor::processInput', function($event) { $inputfield = $event->object; $value = $inputfield->attr('value'); if(strpos($value, 'style=') === false) return; $qty = 0; $value = preg_replace('/\bstyle=(["\'])([^\1]+?)\1/i', '', $value, -1, $qty); if(!$qty) return; $inputfield->attr('value', $value); $inputfield->trackChange('value'); $inputfield->warning("Stripped $qty style attribute(s) from field $inputfield->name"); }); Word may be adding some other weirdness too, but I don't have a good example to look at to know what else there might be (MSO-specific class names?). In any case, we could probably remove it in a similar manner.

Here is a new created version to track changes which works without any problems and you dont have to take care about the deletion of input values if the page was not saved successfully (like in the version before) Put this little piece of code inside your ready.php. //Compare before and after values and output a warning message $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); $page->of(false); //configuration: change it to your needs $templates = ['event_businessvacations', 'event_dates', 'event_events', 'event_specialbusinesshours']; //array of templates where this hook should run $fields = ['summary', 'body']; //array of fields which should be checked //configuration end if(in_array($page->template->name, $templates)){ $changedfields = []; foreach($fields as $fieldname){ if ($page->isChanged($fieldname)) { // Page as it is in the DB $oldPage = wire('pages')->getById($page->id, array( 'cache' => false, // don't let it write to cache 'getFromCache' => false, // don't let it read from cache 'getOne' => true, // return a Page instead of a PageArray )); $changedfields[] = $oldPage->fields->$fieldname->label; } } $changedfields = implode(", ", $changedfields); if(!empty($changedfields)){ $this->warning(__("The following fields have been changed: {$changedfields}")); } } }); Change the configuration block to your needs (template names, field names). This little code snippet outputs only a warning message which fields have been changed - not more or less, but you can also run some other logics - its up to you. Note: Works also with repeaterfields, but you can only check the repeaterfields for changes in general. It is not possible to check for specific fields inside the repeater.