Leaderboard

Sorry for the delay, I’ve posted the PR here: https://github.com/processwire/processwire/pull/251 Since it simply uses an anchor tag with a download attribute, it also allows you to open the full-size image in a new tab using a middle click or “open in new tab”, which is just the behaviour I would expect and seems pretty useful. Your SCSS module is amazing! Unfortunately SCSSPHP doesn’t seem to do exactly what Ryan’s setup does, and I suppose the “self” thing is a bug in SCSSPHP, but a great help nonetheless!

I think a lot depends on the form's purpose, the client's needs and – of course – on how much time you can spend on a given task. For example, I am working on an "online ordering solution", where the management of multiple addresses is needed, and this is what I already have working for this particular purpose: [image has been removed] So, for this form and for other "record management like" forms in the system, I opted for modal windows, toast messages and inline form error notifications (validation messages). I use Unpoly 2 and Bootstrap 5, btw.

Absolutely - I was just thinking that the code for this feature that is in AOS might be useful in preparing the PR for the core.

I personally prefer to show a page/redirect to a page after a successful form submission. The reason for that is quite easy... a few examples: Contact form: I can inform people about how fast they can expect an answer and/or already offer a selection of FAQs - especially when the contact form was used from an info page. Forms on lead pages (newsletters or downloads): I can offer more "options" such as products, services or explain how to make sure they will receive e-mail updates (like "add our e-mail address to your contacts and check for spam"). The last part can be used for newsletter sign-ups as well. In case you offer a newsletter archive, tell and show your visitors about it. Forms on pre-sale pages: In real estate after someone submits a request for a house, flat, office or whatever you can offer already details and downloads they will need in order to rent or buy something and even answer questions. Or even tell them who their contact person will be. You car dealer for example: contact form submission with topic "parts" or "inspection" you could tell them "Mr/Mrs Doe, our expert for parts/inspection will contact you and answer your question. In case you might need it, here are the contact details..." You can even personalize those pages based on the form details, like name, topic, and whatever else. This way a form submission is not a dead end and I can keep the visitor/user a bit longer on the page(s). I really enjoy it (UX) when a contact form isn't a show-stopper but keeps it somehow going. Sure this might not work with every form or super simple contact forms. You might need more data to decide wether to show a page or just a short confirmation. Are there good reasons against it? Probably. Are there good reason for it? Absolutely.

With all the hype about ChatGPT, I wanted to see how useful it could be for us ProcessWire lovers. In a word: wow! It's pretty darn impressive for such early public testing and for such targeted subject. I love how it proposes code with comments, then proceeds to explain it. (Note: I've been getting more impressive and consistent results on mobile for some reason.) Prompt: Filter blog post by category in ProcessWire To filter blog posts by category in ProcessWire, you can use the find method of the $pages object, along with the category field and the equals operator, like this: // Get the category slug from the URL $category_slug = $input->urlSegment1; // Find all blog posts in the given category $posts = $pages->find("template=blog-post, category.slug=$category_slug"); // Loop through the posts and output their titles foreach ($posts as $post) { echo "<h2>$post->title</h2>"; } This code will find all blog posts that are in the category with the given slug, and output their titles. You can modify this code to output other information about the posts, such as their content, images, or dates. To make it easier for users to filter posts by category, you can also create a navigation menu that lists all the available categories, like this: // Find all categories $categories = $pages->find("template=blog-category"); // Output a link for each category echo "<ul>"; foreach ($categories as $category) { echo "<li><a href='/blog/$category->slug'>$category->title</a></li>"; } echo "</ul>"; This code will find all blog categories and output a link for each one, using the category slug as the URL parameter. When a user clicks on a link, they will be taken to the blog page with the posts filtered by that category. Prompt: Login form in ProcessWire To create a login form in ProcessWire, you can use the following code: // Check if form has been submitted if ($input->post->submit) { // Sanitize user input $email = $sanitizer->email($input->post->email); $password = $sanitizer->text($input->post->password); // Check if user exists and password is correct $user = $users->get("email=$email"); if ($user && $user->matches($password)) { // Login user $session->login($user); // Redirect to home page $session->redirect("/"); } else { // Output error message $error = "Invalid email or password."; } } // Output login form echo "<form method='post'>"; echo "<label>Email:</label>"; echo "<input type='email' name='email' value='$email'>"; echo "<label>Password:</label>"; echo "<input type='password' name='password' value='$password'>"; echo "<input type='submit' name='submit' value='Login'>"; echo "</form>"; // Output any errors if ($error) { echo "<p class='error'>$error</p>"; } This code creates a login form that accepts an email and password. When the form is submitted, it checks if a user with the given email exists, and if the password is correct. If the email and password are valid, it logs in the user and redirects to the home page. If the email and password are invalid, it outputs an error message. Prompt: User registration class in ProcessWire with email, password of at least 10 characters and age over 18. Check if email is unique. To create a user registration class in ProcessWire with email, password of at least 10 characters, and age over 18, you can use the following code: class UserRegistration { public function register($email, $password, $age) { // Sanitize user input $email = $sanitizer->email($email); $password = $sanitizer->text($password); $age = (int) $age; // Validate user input if ($age < 18) { $errors[] = "You must be over 18 to register."; } if (strlen($password) < 10) { $errors[] = "Your password must be at least 10 characters long."; } if ($users->get("email=$email")) { $errors[] = "A user with this email already exists."; } // If no errors, create user account if (!$errors) { // Create new user $user = new User(); $user->email = $email; $user->password = $password; $user->age = $age; // Save user to database $user->save(); // Redirect to confirmation page $session->redirect("/confirmation"); } } } This code creates a UserRegistration class with a register method that takes an email, password, and age as arguments. The method sanitizes and validates the input, and creates a new user if the input is valid. It also checks if a user with the given email already exists in the database, and outputs an error if one does. To use this class, you would first instantiate it: $registration = new UserRegistration(); Then, you can call the register method to create a new user: $registration->register($email, $password, $age); Prompt (similar to previous one): User registration form in ProcessWire with first name, last name, email, password of at least 10 characters and age over 18. To create a user registration form in ProcessWire with first name, last name, email, password of at least 10 characters, and age over 18, you can use the following code: // Check if form has been submitted if ($input->post->submit) { // Sanitize user input $first_name = $sanitizer->text($input->post->first_name); $last_name = $sanitizer->text($input->post->last_name); $email = $sanitizer->email($input->post->email); $password = $sanitizer->text($input->post->password); $age = (int) $input->post->age; // Validate user input if ($age < 18) { $errors[] = "You must be over 18 to register."; } if (strlen($password) < 10) { $errors[] = "Your password must be at least 10 characters long."; } // If no errors, create user account if (!$errors) { // Create new user $user = new User(); $user->first_name = $first_name; $user->last_name = $last_name; $user->email = $email; $user->password = $password; $user->age = $age; // Save user to database $user->save(); // Redirect to confirmation page $session->redirect("/confirmation"); } } // Output registration form echo "<form method='post'>"; echo "<label>First Name:</label>"; echo "<input type='text' name='first_name' value='$first_name'>"; echo "<label>Last Name:</label>"; echo "<input type='text' name='last_name' value='$last_name'>"; echo "<label>Email:</label>"; echo "<input type='email' name='email' value='$email'>"; echo "<label>Password:</label>"; echo "<input type='password' name='password' value='$password'>"; echo "<label>Age:</label>"; echo "<input type='number' name='age' value='$age'>"; echo "<input type='submit' name='submit' value='Submit'>"; echo "</form>"; // Output any errors if ($errors) { foreach ($errors as $error) { echo "<p class='error'>$error</p>"; } } Watch out, this is addictive ?

That is very counterproductive. Google might derank your page based on this (Don't know if it is still the case, but it was). Also it is never a good thing to optimize something to specific devices or resolutions. Design for EVERY device. Use progressive enhancement instead of using the user agent string or some other detection for the browser. User agent strings can be manipulated and are not reliable! Also future browsers wouldn't be taken into account. Browser detection is a thing of the past and should be abandoned, as there is no need for it. If you want different images for different resolutions or landscape and portrait view modes, there are media queries for this purpose. Thats exactly what media queries are for. You can even do art direction (display different images on different viewports) with different display modes depending on the display. DO NOT USE BROWSER DETECTION. PERIOD!

@Joss The utf8mb3 listed on your field_article_text table is the same thing as utf8 I think (utf8 is 3 bytes), so that won't support emojis. Check in your /site/config.php file and look for $config->dbCharset and change it to this: $config->dbCharset = 'utf8mb4'; Then try creating a new Textarea field that uses TinyMCE. It should now use that utf8mb4 charset, and emojis should work. If you want to convert your existing field_article_text field, you'll want to export the table and all its data (with phpmyadmin), then edit the resulting SQL file/dump, change the "CHARSET=utf8mb3" to "CHARSET=utf8mb4". Then import to replace the old table. If you get an error, change the KEY length "250" for that data_exact key in the CREATE TABLE statement to "191".

Note that you’re hooking the save() method of “Fields” object. This line makes no sense. I assume you mean “$event->object”, but because you’re hooking a method of the Fields class, I would imagine that will give you the same as wire()->fields(), not the field that was saved. The saved field is the first and only argument of the save() method, so I expect this should work: $field = $event->arguments(0); Apparently, towards the end, Fields::save() also calls Fieldtype::savedField() , so you may want to hook that instead: $this->addHookAfter('FieldtypePassword::savedField', $this, 'updateBlacklist'); protected function updateBlacklist(HookEvent $event): void { $field = $events->arguments(0); if ($field->name == 'pass') { $this->wire('session')->message('works'); } }

@snck I am currently working on implementing Repeater Matrix support. It is basically working but needs some more thorough testing. ATM the setMatrixItems() method seems to be working well. If you like, you can grab a copy from https://github.com/gebeer/RockMigrations/tree/repeatermatrix and test it out. This is how you create a Repeater Matrix field: // first create the blank field $rm->createField('repeater_matrix_test', 'FieldtypeRepeaterMatrix', ['label' => 'Product Content Blocks', 'tags' => 'products']); /** * Set items (matrixtypes) of a RepeaterMatrix field * * If wipe is set to TRUE it will wipe all existing matrix types before * setting the new ones. Otherwise it will override settings of old types * and add the type to the end of the matrix if it does not exist yet. * * CAUTION: wipe = true will also delete all field data stored in the * repeater matrix fields!! */ $rm->setMatrixItems('your_matrix_field', [ 'foo' => [ // matrixtype name 'label' => 'foo label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], 'bar' => [ // matrixtype name 'label' => 'bar label', // matrixtype label 'fields' => [ // matrixtype fields 'field1' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], 'field2' => [ 'label' => 'foolabel', // matrixtype field options 'columnWidth' => 50, // matrixtype field options ], ], ], ], true); Still need to test the other methods for removing/adding items etc. But this one should work. At least it was working in my tests. When testing is completed I will make a PR so @bernhard can implement.

This is one of those rare weeks where I've got a lot of projects in progress, but all are in the middle, none are at a convenient Friday conclusion for this weekly update. In progress are some core updates, Pro module updates, other module updates, and a client project that's keeping me busy. So I don't have anything new or interesting to report this week, but I like to still check in and say hello, and let you know I'm not running low on coffee or anything like that. ? I hope that you have a great weekend!

Detecting mobile for what reason? JS can always detect mobile browser, or touch devices or based on display resolution. CSS can change due to media and/or container queries. PHP has quite some helpers to do the same. The module you mentioned might not be updated and compatible anymore but you could look into it to check out how it detected mobile devices. Btw.: Latte doesn't detect anything. It just helps making templating easier.