Leaderboard

In preparation for testing of the initial (alpha/early beta) release of Padloper 2, I would like to gather expressions of interest. In the past, some of you expressed a willingness to help with testing. It has been many days since and your position might have changed. In addition, I would like to do this in an organised manner so we cover as much ground as possible. The grounds I’d like to cover are usability and technical aspects with a bias towards the latter. Please also note that there are a number of planned features that will follow the initial release. Hence, we shouldn’t focus much on those. These and similar thoughts will be added to a planned features list (more on this below). The main focus of this testing is to make Padloper 2 production-ready. In order to properly organise this testing, I will need to gather some information from you. I will be doing this via Google Forms. The most important detail will be your email address. I will need this in order to inform you how to access Padloper 2 as well as for other necessary communication. I will not use your email address for any other purposes nor pass it to any third-party ?. Other information to be captured in the form would be what areas of testing you will you want to be involved in and your preference for planned features (since I will need to prioritise them). Forms are better than plain emails in this respect. Please note the following if you wish to be involved in the testing programme: Pricing and subscription will follow the model I have previously stated (similar to ProcessWire Pro Modules). However, for the testing programme, your subscription period will NOT start counting down until after the production-ready release. You will still also have VIP support (please note the nature and location of this may change). To be fair to other testers, anyone joining the programme needs to actually spend time testing the product. If you won’t have time to do this, please wait for the production release. This initial release is NOT a production release. Although it may work for some in that regard, it will not be tagged as production-ready (hence the alpha tag). Licences will be the usual three: (i) Basic/Single Site Licence, (ii) Developer Licence and (iii) Agency Licence. I can explain the different between these three if anyone needs clarity. The initial release will have the introductory prices of €150, €300, €900 for single, developer and agency licences respectively. Cooling period will be 14 days (within which a full refund can be requested, no questions asked). Please note that this time period may change for the production release. Here is the link to the Google Form to express your interest in the testing programme. The form will close in 10 days. Many thanks for your patience. Hope to see you soon in the testing programme. I trust you will enjoy Padloper 2 as much as I have had the pleasure (and honour) of developing it ?.

Now that we're in the last couple months of this year, I've been trying to implement a lot of plans that we discussed early in the year. That meant a lot of updates to repeaters in the last couple of weeks (and likely more on the way). But this week, I've been working on another thing we discussed earlier, which is bringing automatic save and live preview capabilities to ProcessWire, independently of ProDrafts, and with full repeater support. In ProcessWire, it's your own code (in template files) that renders the site’s output. ProcessWire delivers a $page to your template file(s), and your template file(s) render it in whatever manner they see fit. In this environment, we need an automatic save capability before we can have a live preview capability. Working on that automatic save capability is what I've been doing this week. I figure that once that is finished, then we'll be able to start developing the live preview capability. I'm glad to report that we now have automatic save fully functional and have tested pretty thoroughly with every Fieldtype/Inputfield I can think of. Unlike in ProDrafts, it also fully supports repeater, repeater matrix, and even nested ones. Actually, it looks like we'll be able to support everything you would want it to. But it's early yet it'll need a lot of testing before its production ready. I've built it into a module called PageAutosave. It requires the latest version of ProcessWire on the dev branch (3.0.189). I'm not yet positive whether this is going to end up as a core module or not. I thought I would gauge interest and see. For now, I'm posting a limited release test version of it in the ProDrafts support board and ProDevTools support board, if anyone is interested in trying it out. The PageAutosave module lets you configure whether you want it enabled for all pages or just for unpublished pages. When needed, you can also optionally choose to limit it to certain templates, certain fields, or certain user roles. Autosave isn't always desirable as it literally means your changes get saved to the $page as you type, so I imagine it's something people might use more for unpublished pages. Autosave is one side of the coin and live preview is the other. The current goal for live preview is to not depend on any particular view or admin interface and instead to just simply have the option of having a window open to a page in the website that detects changes and updates them automatically. So if you had one window open to the page edit screen, and another window viewing the page being edited, you could observe your updates as you made them. Once that is working reliably, we can decide on how best to put an interface around it, and maybe some will also like the option of just having two browser windows open wherever they want them. This won't be the kind of live preview where you'll see every character as you type it, but more likely you'll see updates a second or so after you make them. That's because your edits have to be auto-saved in the page editor, ProcessWire has to call your template file(s) to render the output, and the live preview has to update whatever has changed since the last update. It's that last part of it that I'll need the most help on. Some of you have mentioned htmx as a potential way to accomplish that and I think it looks compelling. And if you know of any other [likely JS-based] tools or technologies that we should also look at, please reply and let us know. I've bumped the core version to 3.0.189 primarily because the PageAutosave module requires updates that are in this version. This version also continues some longer term build out of a couple Fieldtype interface methods across multiple modules, and adds a new 'sorted' JS event that is triggered during sort actions (also used by PageAutosave). But if you aren't going to be installing the PageAutosave module, there's no urgency to update to 3.0.189 if you are on the dev branch and already using 3.0.188. Thanks for reading and have a great weekend!

Thanks, @ryan! This year's end seems to be even more interesting than its beginning) If that is required for the live preview it should be in the core, IMHO) If I understand it right, the core of what we need to build is something listening to a page save event and refreshing the preview page when it happens. Now we have an autosave to generate the events. The other part is reacting to that autosave. I can see 2 ways of doing that: ajax polling and sse (we probably do not need WebSockets as the preview doesn't need to send anything to the server... yet?). The latter (sse) seems to be a better fit, as it should use less server resources, but might be harder to implement (maybe not). Anyway, htmx supports sse (and even ws to an extent), which makes it a better fit than unpoly that doesn't (at least it didn't not so long ago when I checked). Actually, we could go without htmx, just taking inspiration from the principle it is based on. Though taking the ready-made library could be easier. The other part where htmx (or unpoly, or turbo or...) could help, is refreshing not the whole preview page, but only a part of it. Regenerating the whole page markup could be a long process (those 2 seconds in the OP are way too optimistic for many of the sites I have seen). For example, we could regenerate only one PM block markup and sent it to the preview for htmx to swap. But that would require either some standardization of the frontend or some hookable architecture for a developer to implement. The former would break the core PW principle of leaving frontent to the developer. The latter should be possible and would work nicely when rendering RM based content builders the standard way or with a Wireframe. Unpoly is complete framework, which could be used to upgrade PW admin as a whole, but would probably require to do everything its way. For a one place thing or for a more-work-more-customization htmx is a better suit, as it is lower level, as both of you @Craigand @kongondoagreed. If we bring in unpoly, we need to be ready to slowly redo all the admin area with it (which might be a nice thing in the long term). But for one task htmx is lighter solution. And we could even go without it only getting inspiration from it.

@ryan As a possible alternative to having something polling for changes, have you considered some kind of server side push technology for signalling changes to the connected browsers as mentioned above by @Ivan Gretsky? I've been playing with using a thin ReactPHP layer that sends DOM mutation messages to clients using SSE (which has really good support in browsers) and have about 20 lines of vanilla JS in the browser that does the element replace in the DOM when it gets a message over SSE (though htmx could be used for this too). None of the connections in the video are polling. nifty-reactivedash-demo.mp4

One of the many reasons I like htmx. It reminds me of ProcessWire a lot. Out of the box all it does is give you the necessary tools then stays out of your way. Even the author, for some reason, reminds me of Ryan ?.

thank you so much, it worked!! ? I'll check the tutorials, thanks again!

I think so. It is only used with passwords: https://processwire.com/talk/topic/6629-config-httphosts-and-passwords/?p=64888 Quoting Ryan: "That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken."

I'd like to add another vote to the notion of using something like htmx or Unpoly - I like them, a lot. Having used them on various projects, both have pros and cons (like most things) and satisfy different use cases. I know PW is quick, and the template caching improves on things, but I recently launched a site that made use of Unpoly's up-preload and up-instant functionality - the perceived speed of page loads makes it feel like a static site. The client's response on seeing the dev preview was "I was not expecting a like for like copy! Especially one that is that fast." (their emphasis; it was a redevelopment of a bad WordPress build). With Unpoly, I find the modal, popup and drawer UI are great. Having those integrated with the dynamic functionality is a plus, and means I don't have to worry about whichever underlying CSS framework is being used or pulling in a separate dependency to provide that. It's not perfect; some interactions, particularly nested ones, need a bit more care to make sure the server responses and front-end attributes are all present and correct. I also make heavy use of the "compiler" functionality. This is essentially your "$(document).ready()" equivalent which lets you initialise your client-side components (like maps or colour pickers, for example) on both initial page load as well as any time they happen to be added to the page dynamically via AJAX as the result of an Unpoly request. htmx sits at a bit of a lower level, and provides events and a plugin system to extend it and hook into different interactions. When you need to do client-side things, you will still need some javascript to get the job done; or you could use htmx's sister project _hyperscript. Either way, I'd be happy to see any of these become part of the PW admin. ?

Hi! I am trying to build a new version (open source) of the recurring dates module released a few years ago. And I've found myself with a couple doubts. I am building it as a single value Fieldtype module where I want to save the rrule string (to render the UI) but I want to save the actual occurrences of the rule in a second table, so I can use mysql to query the actual dates. Does this make sense? Is there another field around that uses a secondary table to save data? If this is sensible, where should I do it?? sleepValue()? savePageField()? @adrian I think I saw you suffering with the bugs a lot around the support thread haha, so any input on how you would approach the development/refactors of this would be appreciated. Right now on the "big picture" I want to use Alpine.js to redo de Inputfield and looking for advice here on how to do the actual Fieldtype. Also it's the plan to completely rely on rlavin/php-rrule . And this module will only involve the fieldtype/inputfield not the whole rendering modules that came along the original one.

The following video demonstrates how to set up a development server that is 100% ProcessWire friendly and uses all the latest software (PHP 8, MySQL 8, Apache 2). While there are other approaches to it (such as using tasksel lamp), the video demonstrates an efficient and clean way in getting all the latest versions of the software, advanced configuration settings, in addition to setting up SSL. This could also be used for WSL2 since it's ultimately a barebone virtual machine, much like DigitalOcean and similar providers.

Never mind! I solved it! Just was looping selector in the wrong place! foreach ($selected_techniques as $selected_technique) { $selector_ind .= ", relation_individual_technique.relation_individual_technique_select=$selected_technique"; $individuals->add($pages->find($selector_ind)); $output = ""; foreach ($individuals as $match_ind) { echo " <li><a href='$match_ind->url'>$match_ind->title</a></li>"; foreach ($match_ind->relation_individual_organisation as $relation_individual_organisation) { $organisations->add($relation_individual_organisation->relation_individual_organisation_select); $allorganisations = $organisations->explode('id'); foreach ($allorganisations as $item){ $output .= "$item|"; } $final_output = mb_substr($output, 0, -1); } } $selector_org .= ", id=$final_output"; } Never mind! I solved it!

Yes. Using Ajax. There are many way to send an Ajax request to the server: vanilla JavaScript, jQuery (?), Axios, htmx ?...etc. A workflow like this maybe: Create buttons of type 'button' - to avoid them submitting the form normally. Choose the client-side library (or pure JS) that will to talk to the server. Listen to the click events on the buttons. I would probably toggle the buttons. User clicks on I am here: this sends an ajax request to your server. Create a session (or if you wanted, a cookie) to 'register' the user's presence. Populate your log-page. Send back a response to client, toggling the I am here button to a I am out button. This would be trivial if using htmx. User leaves: delete their session in #6. Amend your log-page. If stream still continuing, show I am here button. Stream ends: clear all sessions from #6. Something along those lines, assuming I understood your question ?.

Another thing I found in regards to this. If you, your client or maybe someone who does their SEO or SEM campaigns... most of the tools won't work that great right now. Some (maybe even most) imitate regular clients (browser namespaces and browser strings) therefore end on the gate page and can't crawl the rest of the whole page. So... they either have to manually change that, if possible, or they won't come that far or report wrong numbers. Nothing to worry about right now but to keep in mind. Update / An inofficial addition to this: maybe look up how adult sites deal with it. I can't (or don't want to) link to those pages here. Maybe even use DuckDuckGo for research here.

Count me in!

Hello, @Ksenia! I think it happens because IDs of pages are 1652 and 1674, and `$item` variable converts to ID. When you iterate over pages, you get `$item` to be 1652, 1652 and 1674, which composes into 1652|1652|1674| and then truncates into 1652|1652|1674 when you assign `$final_output` to it. That's why your condition is true and you have "I don't get it!!!" string. For example, if you write on homepage template file `echo $page`, it will output 1 because 1 is the ID of the homepage.

Hi @howsoonisnow90. Welcome to ProcessWire and the forums ?. Not directly related to your question, but you will want to rename your field. ProcessWire uses and prefers lowercase letters for field names. So, viaggi_gallery. Yes and yes. Your viaggi_gallery field is most likely an image field that accepts and outputs multiple images. So, when you do an echo $pages->get('your_field') you are actually telling ProcessWire to output a whole collection of images and it is asking you which one? There are a number of images in here. Secondly, you need to specify what property of the object you want it to out. Maybe an object->url, or object->description, etc. This is just a toString() method kicking in. <?php namespace ProcessWire; $out = ""; // --------- $out .= "<ul>"; foreach($page->viaggi_gallery as $image){ // foreach($page->get('viaggi_gallery') as $image){// would also work // most likely you want a thumb so create one // processwire will only create this if one is not already available // $thumb = $image->size(200,200); // if you want to specify height only and let width be automatically determined $thumb = $image->height(200); $out .= "<li><a href='{$image->url}'><img src="{$thumb->url}" alt="{$image->description}"></a></li>"; } // ----- $out .= "</ul>"; echo $out; Have a look the documentation and the getting started tutorials. https://processwire.com/api/ref/pageimages/ https://processwire.com/api/ref/pageimage/ https://processwire.com/docs/tutorials/ ps: written in browser; please check for errors.

Looking forward to testing this. PW is such a great platform but ecommerce is so much a part of how my clients are looking to make money. I hope this project thrives and the community can keep it vibrant.

Although, I wrote my shop a long time ago. But with pleasure I will test yours too. My store was founded 10 years ago on the Shop-for-ProcessWire v-001 module that @apeisa wrote. But I've rewritten pretty much everything, and I'm constantly adding new features. Conventional store systems don't work for us, as we have many different product properties. In addition, the store has a peculiar sales algorithm. As well as a special payment gateway for a local bank. And also loading goods from the warehouse accounting program.

I’m in!

Dear Ryan, I think you have not been "trying" to..., instead, you have been working hard on them (not just big features you mentioned today, but smaller yet still useful ones, as always). Thank you so much! Maybe it is worth taking a look at Unpoly as well: https://unpoly.com/ Various opinions: https://groups.google.com/g/unpoly/c/aKfjcIZKi4w https://groups.google.com/g/unpoly/c/w5mVyqA5zmg Demo site created by the author: https://demo.unpoly.com/

Hi Ryan, I just gave the module a quick test with my super advanced out of this world builder setup and wow, this really works well! It even auto-saves Mystique-based fields which is absolutely perfect. Also, replacing a single image-field autosaves correctly too. So sweet.

When adding/saving Repeater items the sort order is determined by the "sort" value of each Repeater page, not by any order you might apply to the Repeater PageArray. An explanation of sort values is here. You could use the $pages->sort() method to set the sort value of the Repeater page you're adding and it will automatically update the sort values of the sibling Repeater pages. $thatPage->of( false ); $newItem = $thatPage->my_repeater->getNew(); $newItem->foo = 'bar'; $newItem->save(); $thatPage=>my_repeater->add( $newItem ); $thatPage->save(); // Set the sort value of the new item to 0 and adjust sibling sort values $pages->sort($newItem, 0);

Yes I am using them in production as well. I think most PHP 8 issues in ProcessWire itself have been resolved. There might be some 3rd party modules that haven't been updated in a while that have some bugs, but I don't use them.

This could be seen as cloaking by Google so be very careful doing things like that. More details here: https://developers.google.com/search/docs/advanced/guidelines/cloaking?hl=en&visit_id=637711928893360718-3584950016&rd=1 Feedback on this from Google in the past: Quite a nice read over on this blog about this topic: https://www.findabledigitalmarketing.com/blog/age-verification-gates-and-seo/

@Jonathan Lahijani If I understand what you are asking for correctly, I think it's actually the next item in the class to-do's here -- does this sound like the same thing you are talking about? If so, I've actually reached the next step on that one along with some other updates, and may have it committed this week, so it's definitely on the way.

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?

Hi @Zeka I see, the DB data isn't updated by this method. Also when calling the ->width and ->height properties on image objects it returns the correct new values. But nevertheless we need to update the data in the DB too. (Also I don't know where or for what it is used ATM. ? ) I don't know any API method for updating this via page images or page files. The only thing I know is to alter it via the database object directly: $TABLE = "field_images"; $WHERE = "data='{$image->name}' AND pages_id={$page->id}"; $SET = "filesize=" . filesize($image->filename) . ", width={$image->width}, height={$image->height}"; $statement = "UPDATE {$TABLE} SET {$SET} WHERE {$WHERE};"; $pdoStatement = $database->prepare($statement); $res = $database->exec($pdoStatement); We need to update the filesize, width and height. Ratio is unchanged and can be kept. So depending on your route you already have the fieldname(s) and page id(s) stored in params. The above is a bare example that works but better should / can be used as a function. (?)

I guess you forgot to set the working directory in your crontab. You should invoke Tasker using cron this way: */2 * * * * docker exec --user nginx phpweb bash -c "cd /var/www/html/site/modules/Tasker && LD_PRELOAD=/usr/lib/preloadable_libiconv.so /usr/bin/php runByCron.php" You can skip the docker and LD_PRELOAD parts but you need to set the working directory (cd ......./Tasker). I don't really understand the other problem, sorry. Do you have trouble with the createTask() method called from your own module?

Yeah this is pretty awesome! Since I'm struggeling with carving out time for the RestApi module over the last year (sorry again for not giving your PR much love @Sebi) I'm pretty happy someone is pushing things forward :) Actually I'm thinking maybe this module should be the official continuation of my RestApi Module. For me it looks like it is more advanced and as far as I can tell by creating a single endpoint the way things are used would be quite similar. What do you think? I'm gonna check it out myself now :)

i hope that is not offtopic, but just for reference here is a very interesting solution when dealing with videos: https://cloudinary.com/blog/introducing_the_complete_video_solution_for_web_and_mobile_developers if anybody has already used that service i would be happy to hear opinions.

Straight to the docs!