Leaderboard

This is the next module beside the FrontendLoginRegister module which is based on the FrontendForms module. As the name suggests, it has been designed to easily create a contact form for your site with the following characteristics: Fast and easy integration of a contact form inside a template by using only one line of code Show/hide certain fields of the form depending on your preferences and needs Beside the default fields you will be able to extend the form with additional fields if needed Highly customizable (change order of fields, add custom CSS classes,...) Run as many forms on one page as you want Possibility to offer file upload to upload multiple files, which can be sent as attachments Usage of all the benefits of FrontendForms (fe. CAPTCHA, various security settings,...) Multi-language IP of the sender will be send with the email too, so you can use it for IP-blocking if you will get a lot of spam from a certain IP To render a complete working contact form, you will only need to add this line of code to your template: echo $modules->get('FrontendContact')->render(); The output can differ from the image above, because it depends on your settings and customizations, but it will looks like similar to the form in the image. This module is completely new and therefore alpha stage - so be aware of using it on live sites! It works as expected in my tests, but it will need further testing. You can download the module here: FrontendContact or you can install it via the Processwire upgrade-module from the module directory. Alternatively you will find all files inside GitHub. You will also find a more detailed description on the the download page. Live example of this module: https://www.schulfreund.at/kontakt/ As always, please report issues or wishes here or directly on GitHub. Thanks for testing!

Hi, my current state of RepeaterMatrix (RM) integration is here: https://github.com/gebeer/RockMigrations/tree/repeatermatrix It is based off @bernhard's dev branch. I just merged the latest changes from dev into my repeatermatrix branch. I have basically done what Bernhard suggested and ported over the original RM methods from RockMigrations v1 and did some minor adjustments. You can create RM fields inside the $rm->migrate(['fields]) array like this: self::content_blocks => [ 'label' => 'Content Blocks', 'type' => 'FieldtypeRepeaterMatrix', 'repeaterTitle' => '#n: {title}', 'familyFriendly' => 1, 'repeaterDepth' => 0, 'tags' => 'repeatermatrix', 'repeaterAddLabel' => 'Add New Block', 'columnWidth' => 100, ], Note that I'm using class constants in my Site module for field names. You can of course use ordinary strings here. Alternatively you can create the field like this: $rmfContent = $rm->createField('content_blocks', 'FieldtypeRepeaterMatrix', ['label' => 'Content Blocks', 'tags' => 'content']); And then after the $rm->migrate() method you can define your RM types like this: $rm->setMatrixItems(self::content_blocks, [ 'test_rte' => [ 'label' => 'Test Repeater', 'fields' => [ self::title => [ 'label' => 'Title', 'required' => 0, ], self::images => [ 'label' => 'My Images', ], self::rte => [ 'label' => 'My Text', ], 'my_repeater' => [ 'label' => 'Test RTE in RepeaterMatrix', ], ] ], ]); As you can see, you can also have regular repeater fields inside RM types. Besides setMatrixItems() there are following RM related methods: setMatrixItem(), setMatrixItemData(), addMatrixItem(), removeMatrixItem() There is no way atm to have the full field definition inside the $rm->migrate() method as array definition. That is something that would need some extra work mainly because the getCode() method as is doesn't play nicely with RM fields. But other that that it seems to work pretty well. Actually I'm using it in a bigger project which is still in development and makes heavy use of RM fields with nested repeaters. I would be happy if you and others could test this. @gornycreative wanted to have a play with it some weeks ago. Don't know if he already had the time to look at it. Eagerly looking forward ? It is totally different from RepeaterMatrix but really great what I saw so far.

I did my first talk ever yesterday @ PHP Meetup Vienna!! Once more everything was a lot more work than I first thought, but I'm quite proud of the result ? What do you think? Did I forget something important? It was really hard to put 10 years into one hour... The recording was not planned at first, but I thought I'd just give it a try and everything worked quite well ? If you like what you see please share it with others so that ProcessWire gets the attention that it deserves ? Special thanks to @gebeer for showing me ProcessWire in 2013 ?

<?php $wire->addHookAfter("Pages::saved", function (HookEvent $event) { $page = $event->arguments(0); // early exits based on your needs if($page->template != 'your-static-template') return; // save some variables for later $lang = $this->wire->user->language; $user = $this->wire->user; // create markup for all languages // render everything as guest user $this->wire->users->setCurrentUser($this->wire->users->getGuestUser()); foreach ($this->wire->languages as $l) { // key for page meta data, eg static-german or static-english $key = "static-" . $l->name; // set temp language $this->wire->user->language = $l; // render page and save it to meta data $page->meta($key, $page->render()); } // change user back to what it was $this->wire->users->setCurrentUser($user); $this->wire->user->language = $lang; }); This would save the static markup in $page->meta("static-default") or $page->meta("static-english") etc... You can then do whatever you want with that piece of data ? You could also create files instead of saving everything to the database - depends on your setup which would be better.

300-600kb are pretty large chunks. I would go with files to keep the DB size down.

Sure. I'd like some other people test this before I make the PR.

That could have been me ?

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!

Extends Pagefile to use Cloudflare Images, Stream and R2 storage to serve files. https://github.com/nbcommunication/CloudflareAssets The main purpose of this module is to allow ProcessWire to be used in an auto-scaling multi-instance environment. By serving file assets from Cloudflare, it is not necessary to have all file assets copied to all instances and we also get the benefits of serving assets from a CDN. How it works When a Pagefile is added in the admin or via the API, it is uploaded to Cloudflare's R2 storage service. Additionally, if the file is an image, it is uploaded to Cloudflare Images, and if the file is a video it is uploaded to Cloudflare Stream. When a URL for the Pagefile is requested e.g. $pagefile->url(), the appropriate Cloudflare URL is returned. As ProcessWire's admin still requires the file to be available locally, in a multi-instance setup if a file is not available it is downloaded from the 'master' copy in R2. This module is not yet being used in production. There may be changes to how Images work in the coming months as features are still being rolled out to this Cloudflare service. Cheers, Chris

I'm getting off-topic, but you are 100% correct now that I've searched. Now my curiosity is piqued. I want to find, from the source, what his personal CMS history was! ? Either way, looking forward to future videos!

Thx @BrendonKoz ? Luckily I seem to be right here: https://processwire.com/talk/topic/27692-i-have-to-switch-from-processwire-to-drupal/?do=findComment&comment=227662 At least it's everything I know. And you are right, it does not really matter ? Thank you very much ? Unfortunately I have some hickups in the webcam stream sometimes. I also got that from time to time at home. Not sure where that comes from ? I think maybe it comes from the cheap usb hub and I should likely use a proper usb port for the webcam ? Thanks ?

I figured that was what you were thinking of too while you were giving that answer; in the spur-of-the-moment I would've probably answered the same way. The dependencies are included in the project though and don't (currently?) require a composer install, so you're not entirely wrong either (depending on perspective). Not that it matters, but I think Ryan came from previously using MODx, not Drupal. I don't want to cheat my memory recall, so I'm not going to look it up! I could very well be wrong there too. ? Considering the last-minute changes for setup with your recording, I'd say the end result was spectacular! ...and yes, if you plan to record, using a placeholder where you expect your overlay video will be is what I didn't put into words, but was hoping you'd get out of what I said (somehow?). Thank you for all of the work you put into that. It was well-thought out and well-presented. I wouldn't have thought to use Git to jump around to speed things up during a live coding session; that was a great trick.

I had been going on a quick search result which is probably not accurate; but it said that umami did not handle events or reports (emails). I see from umami.is that it does do events, though the 4 digit precision for numerical event data is pretty strange (unless they meant 4 decimal places). Sadly neither of them accept amount/e-commerce type data - which would be summed, not counted in charts (plausible issue) Statistics can grow and the more indexed they are the more they grow. It would be interesting to run both on the same site for a comparison!

Please let me know when you think I can merge your changes @gebeer

I will be using this hopefully going forward instead of the typical import/export process for my baseline profile, which takes into account workflows that are more familiar to desktop publishers and allows for traditional task delegation - photo, content, layout, section editors, etc. If there is interest in this, I will provide at least the basic core structure and page classes - might be a good advanced example of how things can be done for publishing projects. I don't have an exact ETA, I'm still working on AdminStyleChroma which is my admin theme color manager and I'm also working on a Color Thief image field implementation - both of which will have official threads and releases and when they are ready.

I think his fork is still being run through - the last issue he was addressing was nested repeater matrices and including the RTE fields in repeaters - which I believe was resolved. I haven't run into any issues with his fork in my testing.

I don't know the current state and if you ask me, wait a little for the launch of RockPageBuilder ? But besides that it should really not be a problem to bring support for RepeaterMatrix to the new version of RockMigrations. It should just be pulling the methods from RockMigrations1 into the new module. If you search for "matrix" in https://github.com/baumrock/RockMigrations1/blob/main/RockMigrations1.module.php you'll see all the necessary methods. @gebeer what's your progress on this? ?

This week updates continued with various .js files in the core (for jQuery 3.6+ compatibility). A few external libraries were also updated to the latest versions, including jquery-tablesorter, jquery-ui-timepicker, magnific-popup and vex. And finally, InpufieldTinyMCE has been added to the core! That's a lot of updates, but there's not a lot more to write about these updates because we covered the jQuery updates last week, and InputfieldTinyMCE has been the topic of several past posts. But now we've got everything together and running smoothly in ProcessWire 3.0.216. I think we're now ready to focus on getting the next main/master version out in the coming weeks. There likely won't be an update next week because I'll be traveling for a few days, but will be back to a regular schedule the following week. Thanks for reading and have a great weekend!

Sure, done! Thx for the input ?

Can you not do this? $cl = $languages->get($user->language->name); $blog_title = empty($page->getUnformatted('title')->getLanguageValue[$cl]) ? 'Look Ma No Title' //user’s language title is empty : $page->getLanguageValue($cl, 'title'); //user’s language title is not empty The unformatted value of language fields should be a LanguagesPageFieldValue object that you can ask about language values without fallback: https://github.com/processwire/processwire/blob/dev/wire/modules/LanguageSupport/LanguagesPageFieldValue.php

Just implemented this in combination with a $cache-ing of the $pages->find() query. Lightning fast. if(file_exists($file) && filemtime($file) > $page->modified) { Would it not be $item->modified? Cheers, Chris

I've just encountered the same issue. Tried to install a module on a site I had finished about 5 months ago. Tried adding the various config settings, etc. k07n's suggestion to check the php zip rang a bell. Only then did I see that I was on php 5.x (which I updated to 7.3) and had zip disabled. That did the trick!

I was fighting same issue once. Four hours to understand that I forget to install php-zip ^_^.

This is so common - I do things like this all the time, not just for menus. Does anyone else think this should be part of the core? For now, I wrote a simple flat function: /** * Recursive traverse and visit every child in a sub-tree of Pages. * * @param Page $parent root Page from which to traverse * @param callable $enter function to call upon visiting a child Page * @param callable|null $exit function to call after visiting a child Page (and all of it's children) */ function visit(Page $parent, $enter, $exit=null) { foreach ($parent->children() as $child) { call_user_func($enter, $child); if ($child->numChildren > 0) { visit($child, $enter, $exit); } if ($exit) { call_user_func($exit, $child); } } } With PHP 5.3 you can generate a menu (or whatever else) recursively as simple as this: visit( $pages->get('/menus/main') , function(Page $page) { echo '<li><a href="' . $page->url . '">' . $page->title . '</a>'; if ($page->numChildren > 0) { echo '<ul>'; } } , function(Page $page) { echo '</li>'; if ($page->numChildren > 0) { echo '</ul>'; } } ); Dead simple. I've seen the options for modules etc. that generate menus - they seem to grow out of control with a million options, and my own helpers seem to evolve the same way, and it doesn't jive with the beautiful, self-contained, simple templates you normally get away with in PW. Would it make sense to have a standard visit() method in Page in the core?