Leaderboard

Thanks, Ryan; I see your point. I don't necessarily agree with all of it (apart from the front-end facing modules part, that I fully agree with), but I appreciate you taking the time to explain your view! Also, I'm clearly in the minority here with my opinions ? One last point, though: When I hear someone describe vanilla JS as not fun or inconsistent, I do wonder if they might be, perhaps, remembering JS as it was a long time ago. Modern JS is at least as far apart from JS of 2006 (when jQuery was released) as PHP 8 is from PHP 4 (also from 2006). After being a heavy jQuery user for years I've been getting more into vanilla JS these past few years, and I must say that my impression of it has changed a lot. Anyway, just saying that if you've been on the jQuery side of things for a long time, giving vanilla JS a try may be a positive surprise. Of course if you're super into the jQuery syntax any difference may be a dealbreaker — and that's fine too ?

Jquery still being a dependency to so many higher level js tools is what keeps it alive much more than jquery by itself being a useful tool nowadays. With modern JS you can do many things natively, which made jquery so appealing years ago. E.g. the $(…), which made jquery famous is just document.querySelector or document.querySelectorAll in native JS. Ajax used to be verbose in native js, but fetch is way better. The only real benefit I still see for building new stuff on top of it would be some of its included normalization of certain behaviours across browsers. 4.0 also at least fixed my largest issue with jquery in modern codebases of not having been a native esm package before.

I've always enjoyed PHP, but never really enjoyed Javascript until I started using jQuery. I continue to enjoy using jQuery much more than vanilla Javascript. Using jQuery has not always been about filling in a gap of Javascript so much as it has been about preferring and even enjoying the interface. It’s fun to use, and Vanilla JS not as much, at least to me. PW has some of its API inspired by jQuery, and together they have always felt just right. When it comes to open source stuff, I like to focus on tools that I enjoy using, as that's what keeps me interested and keeps me going. If we were to take jQuery out of the admin, it would be a huge amount of work, and then leave something that would be less interesting to maintain. So I’m not so enthusiastic about taking jQuery out of the admin. Where I would be enthusiastic about it is with front-end modules that might currently be using on jQuery and don’t necessarily need to. Take FormBuilder and LoginRegisterPro as examples (though there are many more). Perhaps those modules don’t need to require jQuery unless one of the Inputfield modules in use requires it. That way, modules like that aren’t introducing jQuery in an environment where it might not otherwise be in use. And maybe there are some Inputfield modules that currently use jQuery and don't need to. Since Inputfield modules can be either admin or front-end, it makes sense to use vanilla JS when possible with those. So yes, I'm all for reducing or removing the use of jQuery in spots, but not so interested in removing it from the admin.

Like last week, this week the focus has been on adding feature requests from our processwire-requests repository. Though I'd like to give it another week before bumping up the version number. Rather than repeating all that was added here, please see the dev branch commit log, which covers them all, several with more detailed notes in the commits. The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. I was excited to see the new jQuery 4.0.0 release this week, which we'll no doubt be upgrading soon (or once out of beta). Here's a quote from the intro of their new post: Some parts of ProcessWire's API were originally inspired by jQuery. It's always nice to see progress there with new versions, especially a new major version. Thanks for reading and have a great weekend!

@rastographicsBreaking HTML templates into blocks, sections or partial files is what Latte supports out of the bocks. Details see https://latte.nette.org/en/template-inheritance. Maybe you can a small writeup of your approach with htmx an PW once you made your way through.

For the custom page classes there is a great video by @bernhard And you can take a look at the Latte documentation, everything is well described here

RockMigrations now has a feature to easily make sure to fire certain migrations only once: $rm->once( "2024-02-11: Simple demo of the new once() feature", function() { bd('I will be executed only once!'); } ); Extensive docs are already in place: https://github.com/baumrock/RockMigrations/tree/dev/docs/once

If I was the vendor of a product that currently has 77% market penetration I think I would keep going on. It is the most popular JavaScript library by a staggering margin: With so many happy customers it's fantastic news that jQuery continues to be updated and supported, and I don't see how its use in the PW core disadvantages users in any way.

Hello @ all I want to share a new module with you, which makes the creation and validation of forms easy. Take a look at the following example of a simple contact form: // A very simple example of a contactform for demonstration purposes $form = new Form('contactform'); $gender = new Select('gender'); $gender->setLabel('Gender'); $gender->addOption('Mister', '0'); $gender->addOption('Miss', '1'); $form->add($gender); $surname = new InputText('surname'); $surname->setLabel('Surname'); $surname->setRule('required'); $form->add($surname); $name = new InputText('name'); $name->setLabel('Name'); $name->setRule('required'); $form->add($name); $email = new InputText('email'); $email->setLabel('E-Mail'); $email->setRule('required'); $form->add($email); $subject = new InputText('subject'); $subject->setLabel('Subject'); $subject->setRule('required'); $form->add($subject); $message = new Textarea('message'); $message->setLabel('Message'); $message->setRule('required'); $form->add($message); $privacy = new InputCheckbox('privacy'); $privacy->setLabel('I accept the privacy policy'); $privacy->setRule('required')->setCustomMessage('You have to accept our privacy policy'); $form->add($privacy); $button = new Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); This piece of code creates a simple contact form and validates it according to the validation rules set. Inside the isValid() method you can run your code (fe sending an email) Highlights: 30+ validation types Support for UiKit 3 and Bootstrap 5 CSS framework SPAM protection Highly customizable Hookable methods for further customization Multi-language You can download and find really extensive information on how to use at https://github.com/juergenweb/FrontendForms. Please report errors or suggestions directly in GitHub. Best regards and happy testing ? If you have downloaded the module in the past I recommend you to uninstall the module completely and install the newest version 2.1.14. There are a lot of changes in the new version, so please test carefully.

This week on the dev branch is ProcessWire version 3.0.235. Relative to the previous version, this one contains 19 commits of fixes and feature additions (see commit log). As mentioned last week, this version adds support for custom repeater page classes. Another significant addition was the upgrade from TinyMCE 6.4.1 to 6.8.2, which covers 13 TinyMCE versions with hundreds fixes, improvements and additions (see TinyMCE changelog for all the details). I did also try to upgrade CKEditor to the latest version (which is also the final open source version of CKEditor 4), but found it was making outbound http requests to ckeditor.com, so I reverted to the previous version. Presumably that was just to preform version checks, but what's the point if it's the final version ever... previous versions didn't do that. It also seemed like it could be for some kind of tracking, so I decided to leave it out for now and revisit it later. Lastly, this dev version of ProcessWire adds an improvement to the ProcessWire installer. Now you can choose either "hostname" or "socket" as the DB connection type. Depending on what you choose, it'll provide the appropriate inputs. Previously the installer did not support a socket DB connection option. Thanks for reading and have a great weekend!

I'm not sure of the context of your call to truncate(), but perhaps you could run the sanitizer on the output of strip_tags()?

Loving that typo ????

Hey @FireWire Whatever you did, it's working now: Downloaded your branch, deinstalled the module first and than installed your new version. All is working fine. Configuration of the settings now all work without getting an error anymore. Great help. Thanks a lot.

I am also still a fan of jQuery for similar reasons that Ryan enjoys using it. After all, its size is smaller than any decent images a page might contain. So, why use vanilla JavaScript's inconsistently developed methods when one can use jQuery, which was always developed with consistency in mind? I am also a big fan of Unpoly, which (to me) IS "ProcessWire" but in the JavaScript world. If I were to modernize ProcessWire's JavaScript code, I would certainly choose Unpoly while also keeping jQuery. They can complement each other instead of conflicting in terms of concurrency.

Makes sense to update to jQuery 4 once it's available and stable, but I must admit that when I read that article my first thought was "holy crap, they are still going on?" ? Serious question to @ryan: what's your take on jQuery these days, do you still see it as something we will be, or should be, relying going forward? I'm not trying to push any agenda here, but I am wondering if you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript. I'm also not going to go into the "but what about Vue / React / Alpine / HTMX / insert-name-of-any-other-library-or-framework-here" topic at this point; that's a whole different subject. Also: all modern libraries are advocating the use of native JavaScript API's instead of "framework specific magic" anyway, so vanilla JS would be a good first step towards something new. In my opinion (which I've probably voiced here on the forums a few times already) jQuery is now largely obsolete. And I'm saying this as a former fan — it was amazing back in the days when native JS API's were very crude and lacking. Today it's more of a problem. For those that don't know what I'm speaking about, one example is the way jQuery handles events: the API is nice, but also hacky and non-standard, leading to the fact that in order to combine (standard) JS events with jQuery events you essentially need yet another library. (And vendor lock-in, intentional or not, is not a good thing.) Personally I find myself reaching for jQuery in pretty much one specific case: many third party plugins/libraries still rely on jQuery. This is less of an issue every year as devs keep moving forward, but there are still many popular plugins that do require jQuery. For every need there is a non-jQuery solution, but it can take a bit of work to find / migrate to. Some things are admittedly more difficult to replace, and one of those is jQuery UI. But since jQuery UI is already in "maintenace updates only" mode, replacing it is likely something that has to be done at some point. (Also... form serialization. That is something they did really well. And no, vanilla JS FormData is not a direct replacement ?) Sorry for the long rant, but I just felt that this needed a bit of context. I for one would be happy to submit PR's etc. that would move us towards fewer dependencies for jQuery if that's something that'd be beneficial for the project. I believe it would be, but that's just me ?

If you like that approach you might like to try the Repeater Depth Helper module which is a development from that earlier idea. It gives you the depth structure for the whole repeater field from one method and also enforces a couple of depth rules to keep things sane.

No not at all. Just for local development. EDIT: not at all = no, we don't use docker for deployments. Main reason: Most of our clients won't pay for the increased cost of a cloud platform. Second important reason: Most of our projects in the end are "just websites" and for that, the bells and whistles a shared hosting environment provides on the cheap are just too good to not use (e.g. email sending without a complicated configuration, managed configuration and automatic updates, and HTTPS support with auto certificate renewal). Also, you can look at some of the other docker topics I have answered on the forum, PW doesn't play too well with cloud environments (e.g. problems with session retention due to the proxying CEs use). I could be wrong, but I haven't digged into it more than I needed to in order to have a clean and simple local docker environment.

Yes, exactly. Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel. It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

Have reworked all my projects with Latte and CustomPage classes and the code is more clean, way easier to read and maintain and more structured now. Definitely recommend diving into Latte and CustomPage classes for new projects to anyone. Both techniques were easy to learn and paid off quite soon in my projects.

@ryan looks like this was added in 4.22.0 and can be disabled: https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_config.html#cfg-versionCheck

According to https://github.com/ckeditor/ckeditor4/issues/5510 it was indeed added to check if the installed version is up to date, but that's still unexpected and — in my opinion — just plain nasty. There should be absolutely no reason for CKEditor to "call home", except perhaps for those subscribing to their commercial LTS version. And if that feature was added just to push paid subscriptions to existing users once security issues are inevitably found from the free version, that doesn't make it any better. Thought about posting a question about that in the issue, but look like they've disabled commenting; doesn't seem like they're interested in open discussion. Migration to TinyMCE feels more and more like the right move ?