Leaderboard

A week ago the new website of the wuppermann group went online. The Wupperman group is a EU-wide operating company with several locations in different countries. Their portfolio is all about steel fabrication. This includes flat producs, tubes & profiles. The technical production is developed by me, Olaf Gleba. The grafic design is supplied by C&G: Strategische Kommunikation GmbH. Homepage: https://www.wuppermann.com Some Impressions: (Secured) Shareholder portal, only available in german language Former screens deleted on behalf of the client. Technical notes: 1. All contents are populated by provided (i name them) content modules (e.g. Repeater Matrix Types) which gets the client what he needs and either prevent him from doing weird stuff. In nearly all textareas formatting is limited to a absolute minimum. For example, image insertion in CKEditor is generally prohibited. Instead there are dedicated fields for modules which holds media contents. 2. This and that.. - vCards are build on the fly with a admin hook on page save. - PrivacyWire as CCM (just a few cookies to handle Matomo and external movie content) - Uses the SearchEngine Module to handle (multilanguage) site search - Email Obfuscation Module for frontend e-mail addresses - Wire Mail Smtp to deliver automated e-mails - Multilingual (german, english, hungerian, polish, dutch) - Ajax driven content (for example on the contact page) - Heavy use of Fieldtype AssistedURL (Fork by @adrian) to provide language dependend, local file linking (fieldname_[de|en] approach) - Login area (closed shareholder portal) with secured file downloads ($config->pagefileSecure = true) - Email New User, Admin Action (create users batcher), Force Password Change for functionality like adding new users with specific roles, Password reset, Change Passwort a.s.o. - Distribution of concatenate/minified css and javascript is cachebusted (happens within my developement environment,- no modules (like AIOM etc.) involved). - Thanks to @ryan* all images are delivered in WEBP format (with fallback). *) s. https://github.com/processwire/processwire-issues/issues/1497 - The site uses a bunch of modules provided by the ProFields Package (for example Repeater Matrix and Table Fieldtypes).

Hello folks, I was working on a forum module which is about 65% done and was wondering if there would be enough interest to continue development. This would be a paid module of course due to the amount of time involved. I should have my workspace set back up in a few weeks, but later today I'll get a feature list and some screenshots of what I have so far and add them to this thread. Thanks for your time ?

@ryan Have you considered putting some new screenshots here? It’s a very popular feature judging from showcase threads, developers here love to show off their images to great effect (it was also asked about in this recent thread, for instance), but it gets almost no love in the public docs/store page, and even in the introductory blog post it can only be seen for a split second in the video. The images in the video are also kind of grey in comparison to @olafgleba’s beautiful display ? I’m sure showing it off on the store page would boost sales some!

I would definitely be interested... if some client would ask for a (PW integrated) forum. Must be at least 10 years now that I haven't had such a requirement. So I am not sure that there still exists a sizable market for (new) forum softwares...

I think Wanze no longer uses PW, it was written here somewhere... "LAST VISITED October 23, 2021"

Thx. The latest ProField Repeater Matrix has the option (input tab) to define the method for adding items. When you choose Images you get the overlay. By default, the image of the matrix type have the same name and is placed along with the type file location (for example: /site/templates/fields/modules_page/matrix_type.php => site/templates/fields/modules_page/matrix_type.svg). Preparing a good looking Image is just up to you then ?

You can translate your "C" inside admin translation files, the right one is: wire--modules--languagesupport--languagesupport-module for each language you can define the setting there. More on setlocale here, if you want to set it via api: Docs

You can configure your locale, according to your server settings, inside site/config.php like this: setlocale(LC_ALL, 'it_IT.UTF-8'); // where 'it_IT.UTF-8' is MY locale setting. You can find a list of all locales here on Stack Overflow

This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.

Anything like this would be beneficial, whether you make any money from it, who knows, that's the risk you take with anything monetary. But being 65% of the way there is better than 35% right? I tried integrating with Flarum once, I got 50% of the way there, registering users on first login to ProcessWire, or however I wanted it to work, but couldn't get users logging into Flarum when they logged into ProcessWire. They had some weird setup as far as I remember and dodged the issue. If its that far along would love to see it ?

Hi @breezer is your new forum different to the one you mentioned in 2018 with a similar post?

Good day, @BitPoet! Are you planning to merge dev branch to have a new stable?

Hey @Wanze do you plan to do something about the PHP 8.1 errors? ? https://github.com/wanze/SeoMaestro/issues/41 Thx in advance!

Just because there is no need for this extra. The client is happy what he got. Coming from Typo3...

Hello Juergen, I uploaded the new FrontendForms.module and everthing is fine now. No warnings in back-end or front-end. This is a very handy and helpful module for building forms. I just miss the examples you have included in the previous versions of the module - they were very informative; it's a pity I didn't kept them after the updates. You have done a very good job. Thank you for your efforts and hard trying. Best regards, Constantine

Then you'll want to get the PageArray of selectable pages as shown in the earlier hook: $selectable_pages = $page->getInputfield('your_page_reference_field')->getSelectablePages($page); Then you can use ->eq() to get any item in the PageArray by its index/position, and use a switch statement to do different things accordingly. // Get all the selectable pages that apply when "your_page_reference_field" is used on $page $selectable_pages = $page->getInputfield('your_page_reference_field')->getSelectablePages($page); // Compare the value of $page->your_page_reference_field against the pages in various positions of $selectable_pages switch($page->your_page_reference_field) { case $selectable_pages->eq(0): // The first selectable page is selected require ('assets/bookingstatus/bookingstatus_step1.inc.php'); break; case $selectable_pages->eq(1): // The second selectable page is selected require ('assets/bookingstatus/bookingstatus_step2.inc.php'); break; case $selectable_pages->eq(2): // The third selectable page is selected require ('assets/bookingstatus/bookingstatus_step3.inc.php'); break; default: // Some other page is selected so handle that scenario... }

Nice Page! But why didn't you just adapt the admin theme to the CI? Thanks to @bernhard this is now very simple ? https://processwire.com/blog/posts/pw-3.0.179/

That's not always a bad thing - if it ain't broke, don't fix it :) There is the module by bitpoet that works in reverse (I think - I have used that one, but not this one).

We upgraded a big multi language site to 3.0.200 and to PHP 8* + MySQL 8 a couple of days ago, several thousands pages, lots of templates and fields (120MB DB). The upgrade went fine, and the site is running super fast! I didn't measure with tools, but just by reaching the URLs of some complex pages and you can see it loading waaay faster. The client could not be happier. ? Fantastic job, Ryan and the other contributors! Thank you, Sergio --- * I used RectorPHP to help upgrading my custom modules, which was nice.

@Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.

For me the opposite is true ? The main reason for that might be my workflows around RockMigrations and custom page classes. Having the fields defined in code directly in the page class is so much easier for me than any other approach I tried. So those additions where very welcome ones for me ? Need some new data for a boat? Go to the boat pageclass file and add a field there. Need a new field for every blog post? Go to the blog post pageclass file and add it... I'm only sharing fields across templates (page classes) when they really have the same purpose (eg a RockMatrix field for the pages content that has several content-blocks like headline, text, quote, etc that should be the same for templates home, basic-page and blog-item). So adding a new content block like "image" for example would make it available on all those templates immediately compared to having to update all templates one by one and adding the new image block to three different fields. For me it feels a lot better to have a single field for a single purpose. Sharing a field for different purposes by overriding settings in template context never felt good to me... I'm using template context a lot, but only to do simple modifications like tweaking the field's label (eg of the title field). One huge benefit of such an approach can be that you get reusable components that you can simply copy from one project to another. That's because the page classes do NOT share fields with other components of your site and therefore are self-contained parts that work on their own. That would not be possible if you shared fields from a central place. Or it would be a pain to reuse single parts of that website. I have been there. I don't want back ?

It's not often I stumble on parity like this, so grabbed this screenshot for posterity ?.

Alternative, if PHP 7.4+ you can use the null coalescing assignment operator: $browserVersion = $t[0] . "." . $t[1] . $t[2] ??= '';

delete " - site name" from module settings and add "site name" if not home page. $wire->addHookAfter('SeoMaestro::renderSeoDataValue', function (HookEvent $event) use ($settings) { $group = $event->arguments(0); $name = $event->arguments(1); $value = $event->arguments(2); $page = wire("page"); if ($page->id != 1 && $group === 'meta' && $name === 'title') { $event->return = $value . ' - ' . $settings->site_name; } });

This module allows you to automatically send an email to a newly created user with their username and password. It also has the option to automatically generate a password for the user upon creation. http://modules.processwire.com/modules/email-new-user/ https://github.com/adrianbj/EmailNewUser The following things are configurable: Whether Send Email option should be automatically checked when creating new user - also affects new users created via API From email address (if left blank it will use the admin email set in the config/php file Email subject Email body - includes the ability to use any fields from the user template using {field_name} codes so these can be put into the body wherever you want. It's your choice if you want to include the password in the email or not. Whether to automatically generate a password. This can be toggled on/off, but even if it is on, you can override it by simply entering a password manually when creating the new user. Ability to control the length and character sets used to make up the automatically generated password. Option to send a test email to yourself to make sure it is configured the way you expect. Because it is generally not a good idea to email passwords, it is highly recommended to use the new Password Force Change module in conjunction with this module. That way the user has to change their password the first time they login which will somewhat reduce the vulnerability of emailing the password. It can also be used for API generated users: $modules->get("EmailNewUser"); // call the module since it is not autoload on the front end $newuser = new User(); $newuser->name = 'newuser'; $newuser->email = 'newuser@gmail.com'; $newuser->sendEmail = true; // only needed if Automatic Email Send is unchecked $newuser->save(); Please let me know if you have any ideas for improvements. PS Thanks to everyone in this post: https://processwire.com/talk/topic/2981-new-user-welcome-message/ for their thoughts and ideas on how to do this.

... and I thought that we in Germany are already tortured with extreme detail. ? Thanks for sharing the explanations!

Note that legislation may differ from country to country. For an example here in Finland one apparently still has to document the cookies, even though "necessary" ones don't require opt-in (or opt-out). IANAL etc. but that seems to be the common consensus anyway ? Here's a rough translation of the descriptions we've been using: wires ProcessWire session identifier. First-party session cookie, expires when the browser is closed. wires_challenge ProcessWire session cookie used to verify the validity of a session. First-party persistent cookie, expires after 30 days.

Setting the header in the template will return the page view in plain code: header('Content-Type: application/json'); So I finally created a new template just for the JSON and didn't put the code directly in blog.php. This works...

So, basically you would just return the JSON-array without writing it to the file? Something like return json_encode($json); Using "echo" would directly print it to the page. However, in this case I guess I would have to provide the template location in my JS: $.getJSON('http://localhost/My_Project/blog/',processPreview); which actually does not work. It does not throw an error, but only works with the actual JSON-file specifically provided as a URL, i.e. http://localhost/My_Project/site/templates/posts.json So I assume the JSON is not returned in the right way?