Leaderboard

We've been running pretty much the same jQuery and jQuery UI versions for the last 10 years or more. I haven't really seen much urgency to upgrade because the versions we have work quite well, and I wasn't so enthusiastic about the amount of work and potential headaches the upgrade might entail. Over time there have been been a few security issues found in the jQuery library, which I've always kept an eye on, but they weren't ever things that affected our usage or caused any concern here. The biggest hangup I had was just that upgrading meant also updating a lot of code that uses jQuery, since many of the changes to the library are not compatible with code written for earlier versions. (Newer versions of jQuery have a slightly less convenient API than earlier versions). I place more value on stability than on having new versions of things. But it's always been in the back of my mind that sooner or later it would be nice to get these libraries upgraded for many reasons. After all, newer means better and faster right? Well, not always, but that's been the theme in jQuery at least, that newer versions of the library have some performance benefits over older versions. For awhile now, ProcessWire has been using newer jQuery version only when $config->debug = 'dev'; and I've been testing that out for quite awhile (maybe a year?). This week we upgraded our "main" core jQuery version from 1.8.3 to the last available 1.x release 1.12.4 (4 years newer), which is the one I've been testing. We also upgraded our "dev" jQuery version from 1.12.4 to 3.6.4, which is the newest available version, released by jQuery last month (March 8, 2023). In addition, our jQuery UI "dev" version is now updated to the newest available version, 1.13.2. After awhile, these "dev" versions will become our main versions, but likely not before the next main/master version. While the core seemed to work fine as-is with the newer jQuery (1.12.4), the newest versions of jQuery (3.6.4) and jQuery UI (1.13.2) required quite a few JS file updates to support, and that's primarily what you'll see in the commit log this week. If you'd like to test the newest versions of these libraries in the ProcessWire admin (in a dev environment), edit your /site/config.php file and set: $config->debug = 'dev'; When you do that, it will also load the jQuery migrate library with logging ON. Meaning, the Javascript console will contain messages about things that need to be updated. There's still work to do in the core here, so if you enable 'dev' mode then chances are you'll see some messages about things in the admin too. The "dev" debug mode also makes it use the newest jQuery UI library. Keep an eye out for any visual glitches or any UI things that don't work. For instance, I found that when using the newest jQuery UI version, the image resize/crop tool wasn't working quite right, though I hope to have that figured out soon. Chances are there may be other examples like that, if using the 'dev' debug mode, so please let me know if you come across any. If you are a module author, your module uses jQuery and you want to make sure it's working well with the new main core version (1.12.4) you can also enable jQuery migrate verbose messages in your javascript console by setting the following two in your /site/config.php: $config->debug = true; $config->advanced = true; I've found that updating code for jQuery 3.6.4 seems to be backwards compatible with 1.12.4, so maybe just using the $config->debug = 'dev'; option is a good bet when testing, but I wanted to mention both options are available. I'll be continuing to update our core .js files for 3.6.4 and jQuery UI 1.13.2, and next week will likely update some of our 3rd party jQuery libraries such as the TableSorter library and others. Also, I've not forgotten about pulling InputfieldTinyMCE into the core, that'll likely be in the next version 3.0.216. Thanks for reading and have a great weekend!

Thanks for the hard work on this @ryan I mentioned this in the AoS support thread as well, but I figure it's worth a mention here too in case folks can't initially figure out why their admin menu dropdowns are broken after upgrade. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

bern hard, https://processwire.com/api/ref/page/meta/ $bern_hards_datas = $page->meta()->getArray(); love $willy

https://www.bmt.net.nz/ This project began as a project to convert a 20 year old Microsoft Access membership and musical production database to a cloud based system. I completed that over a year ago, but then the organisation realised they wanted a new website, and much of the data was already in the system I'd built for them to manage their membership and shows. Building the public frontend required adding a few more fields on the backend, and reorganising some of the data, but most of it was there already. I've used Lister Pro extensively in this project and it's also my first project using RockMigrations. RockMigrations has proved really helpful in adding new fields, testing, then applying to the live site, and although there's a bit of work to go, the aim is to use RockMigrations to enable the whole setup to be installed as a module on top of a clean ProcessWire installation, as I suspect the setup should be useful for other groups, either with or without customisation of the frontend. Other modules I used were Formbuilder Pro for a membership form, Import Pages from CSV (to import exported data from Access database), Wiremail Gmail, to enable emailing to gmail addresses. I also wrote a custom dashboard module and updater. I wrote a modified version of the ListerPro action Send Email to enable sending HTML formatted emails.

A module for ProcessWire CMS to integrate a user registration/login functionality based on the FrontendForms module. This module creates pages and templates during the installation for faster development. The intention for the development of such a module was to provide a ready-to-use solution for user management, which can be installed and put into operation in a few minutes. It works out of the box, but it provides a lot of configuration settings in the backend: Highlights "One-click" integration of an user login/registration system without the hazzle of creating all pages and forms by hand "One-click" switch between login or login and registration option Double opt-in with activation link on new registrations Option for automatic sending of reminder mails, if account activation is still pending Option for automatic deletion of unverified accounts after a certain time to prevent unused accounts Option to use TFA-Email if installed for higher security on login Mutli-language Select if you want to login with username and password or email and password Select the desired roles for newly created users Select, which fields of the user template should be displayed on the registration and profile form (beside the mandatory fields). Fields and order can be changed via drag and drop functionality Offer users the possibility to delete their account in the members area using a deletion link with time expiration Customize the texts of the emails which will be send by this module Usage of all the benefits of FrontendForms (fe. CAPTCHA, various security settings,...) Support for SeoMaestro if installed Lock accounts if suspicious login attempts were made Support of Ajax form submission This module runs on top of the FrontendForms module, so please download and install this module first. UPDATE 03.11.2023: The module is now available inside the Processwire modules directory: Frontendloginregister This module is early Beta stage, so please do not use it on live sites at the moment. If you discover any issues, please report them directly on GitHub ?. Thanks!

Simples: In init.php wire()->addHook('LazyCron::everyDay', null, 'batchRun'); and then in your hook: wire()->log->prune('debug', $days); where $days is set however you want In my case I aded a cronjob to access the site at night so that the LazyCron fires then.

I'm implementing my first site in ProcessWire and I will be migrating some content from a Drupal 7 site. I've just come to considering the blog + comments. I've read @ryan's tutorial post (from 2011!) and I've experimented with the ProcessBlog module, but I'm not convinced. Here's what I don't like It creates a lot of special pages which then become intermingled with what I might call "content pages", e.g. actual blog posts. This makes the Pages menu quite problematic - on an empty install there must have been around 10 items, and if I'm importing a blog with hundreds of posts that menu is just going to be unhelpful as it's clearly not a sensible way to navigate huge content lists. It uses PageReference for a simple options field. So we have "pages" for things like "Always show comments". I realise that in ProcessWire "everything is a page", and in my head I try to say "it's ok, they just mean entity or object or thing, don't think of it as page. Then why use a word that has such strong meaning in the context of a CMS? Oh just accept it. Hmph. Alright." but it seems that this is going to be very confusing for my clients who will use the site I build for them. Perhaps the Select Options field was not available when the ProcessBlog module was created. Needing to edit a page to get to moderate the comments is not natural to me, and it seems that the edit page form brings in an edit form for every single comment. We have hundreds of comments - this is going to be thousands of DOM nodes, and lots of data being loaded every time. Just doesn't seem sensible, as Ryan said in his 2011 post! Comments as a field definitely has a logic, but also seems to bring problems (above) and also makes comments not easily searchable because they - unlike everything else - are not a page. So I'm thinking I might step out in the following direction instead: So, in words: We'd have templates: comments-template and comment-template, with suitable "Family" settings. And blog-listing-template whose children will all be pages using the blog-post-template. The comment-template: uses a PageReference field to point to which page the comment belongs to. can hold any fields we need for comments - the message, the poster's display name and email, optional user ID, date posted, and potentially other user-entered fields. can use normal page hierarchy for comment hierarchy (i.e. replies to comments). could have moderation field(s), although I might be happy with just published/not published for my use-case. I'm not sure about the /admin/ part of the hierarchy but I really just want to indicate that those parts are not publicly accessible. This to me means: Can load comments as pages, so can easily fish out unmoderated comments and link to their posts in-situ. Can continue to edit a blog post without needing to load all the comments. I'd be grateful to anyone who had time to sense-check this idea, or tell me why it's better to do it another way. Thanks ?

The custom user fields will be taken from the user template and mapped to the FrontendForms class. So PW fields will be re-written to FrontendForm fields. Take a look at https://github.com/juergenweb/FrontendLoginRegister#support-for-custom-user-fields Some of the values as set in the PW fields will be added to the FrontendForm fields too. Example: If you take the PW password field and you have set the requirements to at least "1 letter and 1 digit", this requirement will also be used in the Frontendforms input field for the password on the frontend. Validation will only be taken by FrontendForms. Does this answer your question?

Check: https://processwire.com/docs/modules/guides/comments/

Great ? If you had RM < 3.0 be sure to check out this post: https://processwire.com/talk/topic/27504-rockmigrations-??-the-ultimate-automation-and-deployment-tool-for-processwire/?do=findComment&comment=230651

Ah ok - I didn't clock the PHP 8.0 requirement apologies. I just installed on auto pilot without thinking as have used your module before ?. It's odd though as I thought that operator had been supported pre 8. It wasn't a fresh PW install it was an existing project. I don't recall seeing the warning about PHP version, but Tracy Debugger intercepted the syntax error when I refreshed the modules, so I didn't see the default PW messaging. But all running smoothly now anyway thanks.

You don't have to enable JS in PW. And you can't. ProcessWire just manages content for you and then sends data to the user's client, that is visiting your website. Usually that data is HTML markup. In that markup you can tell the browser to load or execute JavaScript. You can either use inline JavaScript like this: <script> alert('I am a JavaScript alert'); </script> That should pop up a JS alert when visiting the page that outputs that lines of html. The other option is to load an external JavaScript file, which would/should work exactly like you wrote above. I recommend to put only this into the file until that works and then proceed: alert('works'); You can use RockFrontend to use the Latte template engine. I love it. This is how it would look in your example: <a href="#"><img src="{$config->urls->templates}images/logo.svg" alt="Manage"></a> <button class="mobile-nav-toggle" aria-controls="primary-navigation" aria-expanded="false"> <img class="icon-hamburger" src="{$config->urls->templates}images/icon-hamburger.svg" alt="" aria-hidden="true"> <img class="icon-close" src="{$config->urls->templates}images/icon-close.svg" alt="" aria-hidden="true"> <span class="visually-hidden">Menu</span> <!-- screen-reader ... accessability --> </button> You could also just use PHP's short tag syntax: <a href="#"><img src="<?= $config->urls->templates ?>images/logo.svg" alt="Manage"></a>

Hi, When including css/script files, I recommend some cache busting technique, like: /** * Adds file modified date as query string and returns URL to given asset. * <script src="<?= assetUrl("assets/js/site-global.js") ?>"></script> * * @param $relPath string File path relative to /site/templates/, such as "assets/css/site.css" * @return string URL with cache busting query parameter */ function assetUrl($relPath) { $fullPath = wire()->config->paths->templates . $relPath; $modified = ""; if (file_exists($fullPath)) { $modified = "?v=" . filemtime($fullPath); } else { wire('log')->error("CUSTOM WARNING: assetUrl() reports: file of {$fullPath} is missing! (current page ID: " . page() . ")", Notice::debug); } $url = wire()->config->urls->templates . $relPath . $modified; return $url; } Add such a utility function to your init.php (or _init.php if you are using it with $config->prependTemplateFile) and call it like shown in the comment above. Whenever possible, instead of <?php echo ?> use <?= ?> I think that helps a lot. Also, good IDE and a good color theme can visually make things a lot easier on the eyes. I have PhpStorm for example which even highlights HTML/CSS/JavaScript properly in PHP strings/literals so it helps me a lot in this and other areas as well (for example writing proper comments and a lot more).

There's these URL/path hooks from ProcessWire 3.0.173 : https://processwire.com/blog/posts/pw-3.0.173/ which seem very promising for the sorts of problems encountered in this discussion.

This week ProcessWire 3.0.214 is on the dev branch. Relative to 3.0.213 this version has 16 new commits which include the addition of 3 new pull requests, 6 issue fixes, a new WireNumberTools utility class, and improvements to various other classes. A newly added $files->size($path) method was added which returns the total size of the given file or directory. When given a directory, it returns the size of all files in that directory, recursively. Improvements were also made to ProcessWire's log classes (WireLog and FileLog) with new methods for deleting or pruning all log files at once. This version also fixes an issue with the front-end page editor (PageFrontEdit) when used with InputfieldTinyMCE. For more details on these updates and more see the dev branch commit log. Something else I've been working on this weekend is a vulnerability scanner blocker and throttler. I don't know if this is an issue for every site, or if it's because this is an open source project site, but we seem to get a lot of vulnerability scanner bots hitting the site. Sometimes they hit the site pretty hard (with hundreds of thousands of requests) and our AWS cluster servers and databases must scale to meet the demand, using more resources, and thus increasing cost. This is annoying, having to scale for a hyperactive vulnerability scanner rather than real traffic. And it always seems to happen in the middle of the night, when I'm not nearby to manually block it. So I'm working on a module that detects vulnerability scanner traffic patterns and then blocks or throttles requests from their IPs automatically. Once I've got it functioning smoothly here, I'll also plan to add it to ProDevTools board download thread in case it's useful to anyone else. Thanks for reading and have a great weekend!

@gornycreative the issue is already fixed on the latest dev: There has just not been a version bump since then.

On this side, I don't really find the spambots or seo bots to be much of an issue, so I mostly ignore them unless they get too aggressive. It's instead the vulnerability scanners that tend to be the issue here. They are fine when they are throttled. But when they are unthrottled (as is usually the case), they eat up a lot of resources. Here's just one basic example: a vulnerability scanner might send through thousands (or tens of thousands) of URL variations looking for SQL files that it can grab, with dozens of different names each, like db.sql, database.sql, backup.sql, [domain].sql, database-[domain].sql, db-[domain.sql], [domain]-db.sql, and so on and on and on. Then add all the extension variations, .sql, .sql.gz, .sql.tar, .sql.tar.gz, and then add every URL with a trailing slash in the site as the prefix path for every check. So just a scan for SQL files in-the-open might account for tens of thousands of requests. And it'll try to do them all in a very short period of time, making the server like ours scale to meet the demand. Yet this is just an example of one vulnerability check out of thousands that it'll do. Once a vulnerability scanner gets started, it'll run for potentially days. But I usually block them well before that. Once I get an email from AWS about things scaling, I watch the logs pretty closely and then start blocking IPs. But the goal is to have the module just block them automatically. What the module does is that it allows you to define suspicious patterns in GET or POST requests, or user agent strings (and it comes with several patterns to start). For example, you might have patterns to match things like wp-login.php, those SQL request variations mentioned above, requests for .py, .cfm, .rb, .exe files, or others that you don't use on the server, requests containing SQL commands in the query string... these are just obvious examples. Then it lets you define a number of strikes till the IP is out. So for every pattern match, the IP gets a strike. So if I set it to "3 strikes and you are out" then once it gets 3 pattern matches, the IP is blocked for a period of time, also defined with the module. If additional strikes occur while an IP is blocked, the block time gets reset so it starts over, ensuring it's always blocked that set amount of time from the last strike.