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!

Ok... so to give you a small update on this and the reason why I thougt about this feature in first place. In my case, this time, the "client"* really needed to be sure that all enabled/installed modules are somewhat/somehow Core/Ryan modules. It's not about Ryan himself, more of... 3rd party-issues. My "client"* needs a solution for a closed environment. All software, even for websites - or in this case - something similar to an intranet, needs to be audited. A website setup will be worked out in the future (hopefully), so every partner/affiliate should be able to clone a repo from Github (based on a master repo with all modules, settings, defaults audited ... - a site profile, ready to use, to be clear here). They trust ProcessWire and believe in Ryan and therefore only wanted to go with his modules in first place, while 3rd party modules are fine BUT... they needed to know about those prior to install them ANYWHERE, or when in testing-stage needed to know if those are "3rd Party" to get them into an audit. As of now we are already a step further and the "client"* looked up more and more, maybe already most of the modules we could need, already by his own DEV team. To make it clear. They looked for things in the modules like base64-encodings, external resources, external scripts, hidden Google Analytics (and similar) calls, and what-not. Their DEV team is awesome... yes, they digged through a lot and were happy so far - even 3rd Party/community modules. There were some issues they fixed already in some modules - can't say which, as I really don't know. But I got an "OK! Let's go." this week. ? * THE CLIENT: The client - is a new company of an old friend of mine - I worked with for 10+ years and they have to audit any software they use for their clients. They used Dr***l, Ty**3, and some custom solutions in the last few years and weren't that happy. A dummy/MVP-setup of mine brought them to ProcessWire with "huge success" (their words). But to be able to release it to more real clients of them, they need to be able to assure some things... which brings us back to my initial thought and question we are working on right now. To make it even more transparent: it's within the financial/automobile/insurace niche - so they are super strict with their contractors and partners (my client/friend). TL;DR: ProcessWire in a niche-software-solution, ready to be cloned from Github but with audited modules without any [shady-ish] scripts or whatever.

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

Just an FYI for everyone who may upgrade to the latest PW dev version today. 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

tl;dr - see below As @flydev pointed out... a page is more than just only a page. The confusion is real. Totally real for... at least me back in the days when I started using ProcessWire, coming from b2cafelog (nowadays WordPress), Drupal, Nucleus, Textpattern and many more "solutions". Yet... I never ever tried to explain a client what a "page" is in ProcessWire. For my clients a page is the last point/instance, in terms of hierarchy in delivering output, aka a real page. I never tried (after the first 10 clients or so) to explain the steps in-between. Even most designers and developers (outside of PW) get this part - and I don't even try to explain it most of the time anymore. For reasons. While everything is a page... you might want to explain it to your client in different terms. I most often use terms like unit, container, wrapper, entity, part of, fracture... or else depending on whatever I talk about. While I use a page as reference in a recipe, it's still an "ingredient, I can reference" for a client. Makes life easier. This "page concept" is NOT about communicating it to the client (for me!), it's for understanding the concept. When you get this... PW is not only your friend, but your best friend, wingman, best man, godfather of... you get the idea. These are/could be all the same - depending on the context and your setup. $page->title $ingredient->title $city->title $user->title Even though one is a page (endpoint) and all others are a page reference, comment, repeater... whatever. You seem to be very new to PW and came from Drupal, which is totally fine, and therefore you might JUST need to explore more parts of how the API and page handling works. This is not a newbie tip at all! It's what I did and I enjoyed it! You worked with Drupal so... you know more complex setups and concepts - I guess. I came from super limited CMS (see above) back then and learned a lot about PHP and whatever you could achieve with ProcessWire. For me it was freedom to do whatever I wanted to do. Till today. tl;dr/Conclusion: Think about 'page' as a concept and not a page. Or... let us know. We are here to assist and help to find a way.

Short answer as I'm slumped on the couch. It seem you already read the structure documentation page and got the idea. About explaining the concept to the client, just use a real analogy. For example, think of a website as a book. In a book, you have chapters, sections, and pages. Similarly, a website is organized into sections, and each section contains individual pages that hold different pieces of content. In ProcessWire, a "page" is a container that holds all the data and content for a specific part of your website. It's not limited to what you see on the front-end as a traditional webpage. Instead, a page in ProcessWire can represent various types of content or data, such as blog posts, products, images, or contact forms. Once that said, and once you got the « Wow this is flexible! » then you can go further and say that using this tool (some of us call it a framework more than a simple CMS) allow you to build other types of applications than a website. I mean no frontend, no colors, no (web)Pages. You can find somes use case threads arround the forum. Ask for more. Just adding that once your clients become familiar with the page-based concept and the benefits of it, they will find it easier to manage their website content. Enjoy ?

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.

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

Perhaps you could increase the php memory limit if it's set low. https://documentation.mamp.info/en/MAMP-PRO-Mac/FAQ/PHP/Increase-the-PHP-memory-limit/ Otherwise, can you describe more specifically what you're trying to achieve when development feels slow?

It used to be on TV in Germany every night, so maybe that? ?