Leaderboard

This week we have some very useful new additions to both the core Repeater Fieldtype and the ProFields Repeater Matrix Fieldtype. This post covers all the details along with a couple of brief demonstration videos— https://processwire.com/blog/posts/new-repeater-and-repeater-matrix-features/

RepeaterMatrix v7 is now posted in the ProFields download thread. If you grab a copy, please consider it a dev/beta version (test thoroughly before using in production) and note that it also requires the current dev core version (3.0.187).

Hi Ross. ProcessWire has zero-influence on how your frontend looks like or what strategy you adopt to present your frontend. This is 100% up to you. It is the result of the code you have in your template files. So, what you inherited was the previous developer's strategy for outputting frontend content. In short, ProcessWire does not get in your way. In contrast, it does offer you the tools (via its API) to do various things including fetching data from the backend to show on the frontend. In this respect, it does not matter if your ProcessWire version is 2.3.1. However, there have been numerous improvements to ProcessWire since 2.3.1, too numerous to list here, that make it compelling to upgrade to version 3.x. How to upgrade from a version that far back is a topic on its own but there are threads in the forums (and maybe something in the docs but I am not 100% sure) to help you out. Let me quickly point out that It is not required to upgrade. ProcessWire 2.3.1 is perfectly safe to use. As for responsiveness, that is up to you and your CSS. How are your skills in this area?

@nbcommunication Thanks, I was able to duplicate and fix the issue and it is in 3.0.187.

I am starting to study programming and css. This motivates me to learn. Thanks for your tips.

Hi, Is anyone else finding that noSlashUrls is no longer respected on top-level (e.g. /page-name) pages on 3.0.186? Cheers, Chris

Great additions! Have not tried'em yet, but my next week will be full of fun) Thanx, @ryan! I was amazed to see my name in the blog post, but I need to say that all the credits for those images should go to @David Karichas they were taken from his fundamental video. By the way, everybody caring about the future of PW and its infrastructure please ??? donate to David as a creator, who shapes the things we use (and dream of), so he feels even more motivation to keep doing his thing. He asked for the support. And of course, go get your copy of ProFields if you have not already, as that is one of the coolest ? things you can get for your PW site and supports PW development as a whole. Sorry for the emojis, but it is late friday night here where I am at and I feel exited)))

Hi Ryan, Just gave 3.0.187 a whirl along with the new version of Matrix and it's looking really great. I wanted to get your thoughts about a potential optimization to repeaters (which would also apply to matrix). Right now, if you add a repeater field (let's call it 'my_repeater') to a template, then create a new page (let's call it 'p1'), ProcessWire will create a "for-field" page and "for-page" page in the following fashion: /admin/repeaters/for-field-123/ title = my_repeater /admin/repeaters/for-field-123/for-page-456/ title = p1 That's all good, but when utilizing RepeaterMatrix as a page builder in the way that I do, it can get a little insane with how many 'for-page' pages get automatically created, even if a repeater field is not being used for a particular matrix-type. In my advanced setup, if I apply a single matrix type to a page, then as a result of having 6 different repeaters as part of my overall matrix field, 6 'for-page' pages will get created behind-the-scenes no matter what. Now imagine a page with 20 instances of various matrix-types used, that means there will be at least 20*6 pages that have been utilized behind-the-scenes which can lead to performance issues (deleting a page like that takes some time). I could demonstrate this with a video, but I think you know what I mean. So in short, is it possible to somehow improve repeaters so it's more efficient with the creation of 'for-page' pages?

Happy coding ?.

Thank you, @horst! I did what you suggested, the transparent pixel as a source works well and we started optimizing the images because they were huge PNGs.

Hi @Marcel, you can find the "AppAPI" config page with following schema: {{YOUR_DOMAIN_COM}}/{{ADMIN_PATH}}/{{SETUP_PATH}}/appapi/ For a "default" ProcessWire installation on "example.com" this would be: https://example.com/processwire/setup/appapi/ There you need to manage your applications. Then, in your Router.php file you need to define routes (=endpoints).

I have tested and it worked perfectly! I am very grateful for the help! Ross

Do these inputfields have a column width set so that they all appear in the same row? If so then I think it is recent core behaviour that collapsing one inputfield in a row collapses all the fields in the row. This didn't use to happen but it did make for some weird gaps and outline anomalies when a single inputfield in a row was collapsed, so the new behaviour is probably better. So if you have an inputfield that will usually be collapsed I think the best thing is to put it on a separate row within the fieldset.

the following is a transparent 1 px gif: <img src='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' ... If you use this as default src, together with the width and height attributes, the browser engine is much earlier ready (doc-ready). You ommit one extra server request per image, as the images default data is already available within the HTML. And the default data is thousand times smaller this way. All that speed up things drastically. To your other points: 2) As I understand the concept of srcset, you should use / load the smallest fit, and if the image should be zoomed / scaled up afterwards, the browser handles additional (re)loadings.

Hi everyone! @csaggo.com Sorry for the delay. I had some sick and stressful weeks, but I hope that it will become better now. I just released a new version 1.1.7 that fixes @csaggo.com's problem that he mentioned above. The module's /auth-endpoint does now accept the login-credentials in different formats. You can now send username and password in a JSON-formatted (or FORM-URL-Encoded or Multipart) POST-body. It is even possible to send the credentials as GET-params - although I would not recommend it. A short note to what went wrong in the previous versions: I myself forgot to use my own (extremely useful) parameter functionality, which extracts parameters from a wide variety of formats: public function ___doLogin($data) { // ... // The right way to get params: $username = $this->wire('sanitizer')->pageName($data->username); $pass = '' . $data->password; // Old code: // $username = wire('input')->post->pageName('username'); // $pass = wire('input')->post->string('password'); // ... Please use the $data-object that your api-functions will receive automatically - this process is more tolerant than Processwire's wire('input')->post when it comes to different body formattings.

// requeire https://processwire.com/modules/file-validator-svg-sanitizer/ and $svgSanitizer = $this->wire()->modules->get('FileValidatorSvgSanitizer')->getSvgSanitizer(); $svgSanitizer->minify(true); $svgSanitizer->removeXMLTag(true); $data->setArray([ 'inline_svg' => $svgSanitizer->sanitize($this->wire()->files->fileGetContents($category->get('svg')->filename)), ]);

If you are using FormBuilder you might want to take a look at the FormBuilder section of this forum as well. There are many solutions to all kinds of issues. I your case - but that is just a guess - it seems either your hosting is issues sending the mail (security modules in Apache maybe or missing modules) or your form wasn't embedded in the correct way. Saw this a few times when I added the form twice on a page or missed some scripts.