Leaderboard

I'm currently building a Fieldtype/Inputfield for selecting date and time ranges (eg for events). There was quite some interest in this thread, so I thought I start a dedicated discussion... Background: I guess everybody of us knows the problem: You want to present events on your website and you start with a new template and a title and body field... For events you'll also need a date, so you add a datetime field called "eventdate". Maybe the event does not take place on a specific day but on multiple days, so you need a second field... Ok, you rename the first field to "date_from" and add a second field called "date_to". So far, so good. Then you want to list your events on the frontend. Simple thanks to the pw API, you might think. But you realize that it's not THAT simple... Which events take place on a specific day? What would the selector be? Yeah, it's not that complicated... it would be something like: $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01"); $events = $pages->find("template=event, date_from<$to, date_to>$from"); Why? See this example, where the first vertical line represents the $to variable and the second is $from: The start of the event must be left of $to and the end must be right of $from ? Ok, not that complicated... but wait... what if the date range of the event (or whatever) was not from 2020-01-18 to 2020-02-25 but from 18 TO 25 (backwards)? The selector would be wrong in that case. And did you realize the wrong operator in the selector? We used date_to>$from, which would mean that an event starting on 2020-01-01 would NOT be found! The correct selector would be >=$from. That's just an example of how many little problems can arise in those szenarios and you quickly realize that the more you get into it, the more complicated it gets... Next, you might want to have full day events. What to do? Adding a checkbox for that could be a solution, but at the latest now the problems really begin: If the checkbox is checked, the user should not input times, but only dates! That's not possible with the internal datetime field - or at least you would have to do quite some javascript coding. So you add 2 other fields: time_from and time_to. You configure your date fields to only hold the date portion of the timestamp and show the time inputfields only if the "fullday" checkbox is not checked. We now have 5 fields to handle a seemingly simple task of storing an event date. That's not only taking up a lot of space in the page editor, you'll also have to refactor all your selectors that you might already have had in place until now! Idea So the idea of this module is to make all that tedious task of adding fields, thinking about the correct selectors etc. obsolete and have one single field that takes care of it and makes it easy to query for events in a given timeframe. The GUI is Google-Calendar inspired (I'm acutally right now liking the detail that the second time input comes in front of the date input). I went ahead and just adopted that: Next steps I'm now starting to build the FINDING part of the module and I'm not sure what is the best way yet. Options I'm thinking of are: // timestamps $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01")+1; // last second of january // option 1 $pages->find("template=event, eventdate.isInRange=$from|$to"); $pages->find("template=event, eventdate.isOnDay=$from"); $pages->find("template=event, eventdate.isInMonth=$from"); $pages->find("template=event, eventdate.isInYear=$from"); // option 2 $finder = $modules->get("RockDaterangeFinder"); $finder->findInRange("eventdate", $from, $to, "template=event"); $finder->findOnDay("eventdate", $from, "template=event"); ... I think option 1 is cleaner and easier to use and develop, so I'll continue with this option ? Future As @gebeer already asked here I'm of course already thinking of how this could be extended to support recurring events (date ranges) in the future... I'm not sure how to do that yet, but I think it could make a lot of sense to build this feature into this module. I'm not sure if/how/when I can realease this module. I'm building it now for one project and want to see how it works first. Nevertheless I wanted to share the status with you to get some feedback and maybe also get your experiences in working with dates and times or maybe working with recurring events (or the abandoned recurme field). For recurring events the finding process would be a lot more complicated though, so there it might be better to use an approach similar to option 2 in the example above.

There might come many posts in the near future, sorry for that. I'll use this thread to let you follow and to have some kind of notes for writing docs when I release the module... It's also easier to quote and link to a specific post than to a section of one long post. The field now has 2 settings for hiding the checkboxes for toggline the fullday and has-end setting. This means you can use this field as a replacement for the datetime field and use the custom selector options shown above (range.onDay/inMonth/inYear).

Even though not officialy supported by PW3 I've used this module in the past successfully: https://processwire.com/talk/topic/711-release-schedulepages/

To be fair publishing (or un-publishing) pages at set time vs. just listing pages based on a datetime field are two different use cases. In some cases the distinction may not matter, but in others it will — i.e. when something really shouldn't be viewable before a predefined date/time ?

@nabo What's your use-case? From a security point of view it's not a good idea to allow everything. Surely you have an idea what kind of file-types will be used? I found another forum thread where basically the same question was asked, and the gist of it was: No, you can't. Leaving the allowed extension config list empty makes it unusable, and just entering a wildcard * won't work either. @ryan takes security matters very seriously, and personally, I wouldn't want to have such a "everything goes" option built-in the core, too. If you have to, for some reason, import data from another system, and create / populate fields via API (batch actions), you can temporarily allow each file extension that comes your way, and then switch back to a "normal" default set after save. But I guess you were asking about using the GUI options.

I think this already looks quite promising ? $selectors = [ "template=event", "template=event, range.inRange=2020-01-01;2021-01-01", "template=event, range.inRange=2020-01-01;2020-02-01", "template=event, range.inRange=2020-02-01;2020-03-01", "template=event, range.inRange=2020-04-01;2020-05-01", ]; foreach($selectors as $selector) { $out = ''; $nl = ''; foreach($pages->find($selector) as $p) { $out .= $nl.$p->getFormatted('range'); $nl = "\n"; } d($out, $selector); } This now also works with backwards ranges (eg 19.3.2020 to 10.2.2020) because I store a separate START and END timestamp in the database: I've also implemented onDay, inMonth, inYear selectors: $selectors = [ "template=event", "template=event, range.onDay=2020-04-15", "template=event, range.inMonth=2020-03", "template=event, range.inYear=2021", ]; This also works using timestamps: $stamp = strtotime("2020-04-15"); $selectors = [ "template=event", "template=event, range.onDay=$stamp", "template=event, range.inMonth=$stamp", "template=event, range.inYear=$stamp", ]; Even sorting works out of the box - PW is once more impressive ?

That looks great so far, will be a really useful fieldtype! I also prefer option 1. Much cleaner than having to involve yet another module. This would be so awesome. Especially since the Recurme module seems to have passed away silently. Maybe you can get some inspiration from there on how to handle recurring stuff. I wouldn't include the whole render a calendar stuff. People who need it can always use some existing framework for that. Would be great if you could share the code pre-release on GH so people who are interested could collaborate. I did some date manipulation in the past because I'm involved with quite a few sites that needed it. What I found most challenging is the timezone calculations. Also did some recurring stuff as far as I remember. What I found very helpful at the time for those tasks are the PHP DateTime, DatePeriod and Dateinterval classes. Haven't delved into it for some 3 years but remember that it actually was fun. I guess today I would use the recurr library. EDIT: As for the recurring events, I'd probably make this optional in the field settings and only present the inputs if needed.

I worked hard on the module the last days, and rewrote much of the core logic and added some more features. I wanted to record a screencast yesterday, but my recording software ignored my mic. So I show you some annotated screenshots instead. Since then, many things changed again. Right now I am working on downloading and installing a module via a URL, and also making a transition to modal dialogs instead of panels, if applicable. I moved the whole button logic from the PHP script to a vue component. So I am flexible how to display the buttons, and I can reuse them in the cards and in the table layout: I added a reduced card layout, which moves the description of a module into the "more information" accordion: Updated TODOs with much more features to come. I will work on the module in the next 2 days and hope to make so much progress, that I can finally release the first version on github.

For 90% of these kinds of cases I do it like @Jens Martsch - dotnetic suggested, and in the template of the page (event, news item, etc) I have: // Throw 404 if item is future-dated if(!$user->isLoggedin() && $page->getUnformatted('date_1') > time()) throw new Wire404Exception(); But on a complex site where the pages might be queried from many selectors in many different places then unpublishing is the way to go.

So I'm the looser coding my hook on every site ?

Another SchedulePages user here. Works just fine for PW3 ?

Thanks. That is helpful. I think I'll do it that way instead.

Hi @saschapi! I'm not aware of a module that enables this along with lazyCron but you could try placing something like this under site/ready.php $wire->addHook('LazyCron::everyDay', function($e){ $posts = $this->pages->find('status=unpublished, template=post'); foreach($posts as $post){ if($post->schedule_publish_date <= time()){ $post->of(false); $post->status([]); $post->save(); } } }); The page template you want to publish, would have a schedule_publish_date field, where you can set a publish date and time.

@bernhard Thanks for this discussion, it is great that you raised this issue this way. I've found another one: https://github.com/rlanvin/php-rrule this one does not seem too have to many issues but it is hard to tell... I think supporting recurrence out of the box might be a good idea as adding it later might generate unnecessary refactoring work. I am just guessing though... As for time zones, most projects can do without it, so if I were Bernhard I would not deal with it.

Hi @JC_G it can be and in most times it is that simple. Only thing I spotted is the version 2.5.7. I remember that there were some changes in regard of image (naming) processing around 2.5.11. So it can be a good additional check to look if there are some image related inputfieldtypes in use. (Check the modules - site screen, and if you find something like thumbnail- or croppable-image modules, please post there names here and I may provide some tipps or links, if necessary). But you also just can install it in a testversion on the new server, upgrade Processwire core to the latest stable and test and look if everything is working as expected.

Hi @JC_G and welcome to PW and the forum ? Make sure PW runs smoothly on the new server (go through the step by step installation process of the current version) If that works, make a zip file of all files of the old website and do a database dump Copy over the files to the new server, restore the database This can be all there is to do. If something goes wrong, just tell us what the exact problem is. There are also tools like https://modules.processwire.com/modules/duplicator/ that you can use. For upgrading there is a guide in the docs: https://processwire.com/docs/start/install/upgrade/

I was tired of adding 6 different fields to an event-template just for storing the time range of the event... ?

Hi @uncle_bobson and welcome, if I understand you correctly then what you are asking it not related to ProcessWire... Or does the data come from the PW backend? Here's a simple example of an auto-updating ProcessWire page that shows the current time taken from http://worldtimeapi.org/ (updating each 5 seconds): // default site profile home.php $content = <<<out <h3>Live Data Example</h3> <div id="livedata"></div> <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment.min.js"></script> <script type="text/javascript"> function getData() { $.getJSON('http://worldtimeapi.org/api/ip', function(data) { var timestr = moment(data.datetime).format('MMMM Do YYYY, HH:mm:ss') + " (" + data.timezone + ")"; $('#livedata').text(timestr); }); setTimeout(getData, 5000); } getData(); </script> out;

If I understood this correctly (instead of text, there's now just an icon?) I would actually recommend against this — simply because icons will never be as obvious as text labels. From an usability point of view text labels are much better ? From an accessibility point of view, on the other hand, this is just fine — as long as your checkboxes still have proper labels. If the icons are images an alt text is quite enough, but if they're something else (<i> with FA classes etc.) you should hide them from screen readers with aria-hidden="true" and then introduce a separate screen reader only text version.

If I understand you correctly, you are looking to add Ajax updated section to your page. This is indeed possible, See Here for an example. If by chance you are using vanilla javascript then check out this post.

This is really only necessary if you are dealing with user input of users from different time zones. You'd also have to know the timezone of the logged in user. For projects where I needed that, I had a field in the user template to save the timezone and did calculations based on that. It is hard to foresee how other people implement it and therefore in the fieldtype you would not know how to get the user timezone. Maybe in a hookable method that by default returns the local server timezone. Then people could hook into it and provide the user timezone only if it differs from the server timezone. The common base for calculation between different timezones is the unix timestamp. So the resulting timestamp for 01.01.2020 20:00 will be different, depending on what the timezone is. The DateTime class has the setTimezone method which helps for conversion of DateTime objects between different timezones. Here's a quick read on the basics.

We can't believe it either ?

Managed to miss this one. Check /site/config.php, you should find the database host/domain, credentials, etc. from there.

Hey! Bernhard already summarised the steps quite nicely above, but one thing I'd like to add is that if you do run into Windows specific issues, you might find solutions from some of the existing threads — e.g. On a loosely related note, the forum search can be pretty horrible at times, so if you're looking for something specific you'll usually have better luck googling for it (site:processwire.com/talk) ?

PwQuickFixes This module is intended to serve as a collection of ProcessWire fixes that can easily be enabled via checkboxes in the module's config. It is NOT intended to be a replacement for github issue reports or pull requests! The idea is that we have a place where we can put fixes for issues that are not yet fixed in the core until they get properly fixed there. It is also not my intention to put pressure on Ryan to fix issues quicker. The idea is that we have a place where we can share our fixes across projects and across users and maybe get a better feeling on the "impact" of different issues. The module could also make it easier for Ryan to test issue reports and the solutions provided by the community: Intended Workflow Identify an issue Create the related files in the fixes folder of this module Create a PR so that I can merge the fix and everybody can use/test/improve it Create an issue in the official PW issues repo and link the fix in your description Usage Just add your fixes in the fixes folder and activate them in the config of this module (via checkbox). See the Foo example module how to add JS and CSS. https://github.com/BernhardBaumrock/PwQuickFixes

Hi, I just uploaded the first version of the SchedulePages module to Github: https://github.com/f...r/SchedulePages This plugin module allows you to schedule (un)publication of pages. I hope you guys will like it. //Jasper Usage: ====== Place the SchedulePages.module file into the site/modules folder and install the plugin from the admin area. Install/activate the LazyCron module (if you haven't already). This module is part of the Processwire core, but it isn't activated by default. Add the following date fields to your template: publish_from publish_until Note: the fields are already created during the installation of the module That't all. LazyCron will run take care of (un)publishing your pages that have a the publish dates set. It will run on every hour. Please note: LazyCron hooks are only executed during pageviews that are delivered by ProcessWire. They are not executed when using ProcessWire's API from other scripts. Edit: Changed the name of the module and function as Ryan suggested below. Edit 2: Updated instructions. Required fields are now automatically created and from now it runs every hour. Edit 3: Added module dependency. The updated module is on Github

@teppoThanks for the feedback. I'll just do periodic polling. Its fine. If I need quicker updates, without spamming so much, I'll just use the "long polling" hack, or signalR. I see now that there would be no problem using signalR with processwire. My confusion was really about howto use vuejs with processwire. As both of them generate the html code for a page, they would be stepping on each other toes. I somehow thought i absolutely needed vuejs, if i was going to do any dynamic changes in the DOM. But I can generate the page with processwire, and then just use jQuery to do the dynamic updates to the DOM.

@bernhard Thanks for the code. Very helpful. The solution to the problem looks so simple now. I'll just generate the page in processwire, and use jquery doing the rest query, for finding the correct element by id, and for updating the DOM. I don't need to use vuejs, at all. It would just complicate matters.

SignalR apparently uses WebSockets behind the scenes to achieve a "real" push effect. I'm not at all familiar with this technology, but if you really need push (instead of polling the server periodically as in the example above — which, for the record, is in most cases quite enough), you could look into something like Ratchet (a PHP WebSocket implementation), or perhaps build that part of the site in JS and then use pretty much anything as the back-end (Node, etc.) Anyway, you're right in assuming that ProcessWire doesn't have anything built-in for this particular need. ProcessWire provides tools for managing content; what you do with that content is not its concern, and technically "pushing the content to the client via WebSocket" is more a matter of presentation than content management ?

I think my answer solves the problem, that the topic poster wanted to solve. Sometimes you have to think outside the box, and I think he just wanted to know how to not show pages that have a publish date in the future. What first comes into mind is: Leave the page unpublished until the date is actual. That you can tackle this problem differently may not be obvious. But you are right @teppo that there might be other use cases, for example if the page url should not be reachable at all, then the published or unpublished status would be the right thing to do.

Title text is not a best practice when it comes to usability; visible text would be best. Not just because things shouldn't be hidden (unless there's a good reason for it, which I really don't see here), but also because it'll be a problem from accessibility point of view, for touch screen users, etc. Overall there are very few cases where the title attribute should be used ? This makes sense ? I think your suggestions are already pretty good! "Show time input" could be just "show time" perhaps? And "show end input" could also be something along the lines of "date range", though not sure about that one. This brings to mind one question: what do you think about making the labels configurable? For an example if we're talking about events, a label such as "all day event" would probably make most sense (and Outlook Calendar uses this as well, so it's somewhat likely to be familiar to users), but events are not the only use case, so the default label probably shouldn't mention "event" specifically ?

I exported the site with ryans ProcessExportProfile Module and did a fresh install. This solved the problem. But would be nice to know what caused the issue. Thanks Adrian for your quick response and your support. Your posts were often helpful und a good resource for learning ?

You could also do this with a simple page selector, which would be the simplest solution: So all your pages have the status Published, but will not be shown, because the event_start field is lower than the today date. $events = $pages->find("template=event, sort=event_start, event_start>=today"); The hook from @elabx is really overkill and modifies the page, which is not needed.

Same here.

"Internal Server Error" or "Page Not Found"? The latter is what you should be seeing for inaccessible files, and that's the correct thing for ProcessWire to do according to HTTP standards. If you see an internal server error (status code 5xx), something's wrong. For a "Page Not Found" error, PW renders the "404 Not Found" page under "Home" unless you have configured a different page as $config->http404PageID in site/config.php. You can create your own error page template and change to that in the page properties to adapt the output and make it more dynamic.

Great. Can't wait to see it (if you plan to release this) ? Any plans for recurring events?

basic example / ideas: document.addEventListener("DOMContentLoaded", function (event) { const trackedLinks = document.querySelectorAll("#content a"); // adjust selector as needed trackedLinks.forEach(function (n) { n.addEventListener("click", function (e) { e.preventDefault(); const href = e.target.getAttribute('href'); console.log(href); // api = special page with tpl and URL-segments enabled: fetch(`/api/linktracker/?url=${href}` , { method: "GET" }) window.location = href; }); }); }); (That's vanilla JS / ES6) if ($input->urlSegment1 === 'linktracker' && isset($_GET['url'])) { $url = trim($_GET['url']; // save to a textarea inside PW: $pg = $pages->get("123"); $pg->of(false); $pg->linktracker = $pg->linktracker . "\n" . $url); $pg->save(); // save to a custom DB table: $myDB = new PDO("mysql:dbname=linktracker;host=localhost", "root", "******", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $trackLinkQuery = "UPDATE tablename SET click_count = click_count + 1 WHERE url=`$url`"; $query = $myDB->prepare($trackLinkQuery); $query->execute(); // udpate a text-file file_put_contents('path/to/file.log', $url); // if those links are saved inside repeaters or similar, add one int field that you can increment / update: $pg = $pages->get("123"); $pg->of(false); $pg->linktracker = $pg->linktracker +1; // or whatever / wherever your field is.... $pg->save(); } These are 4 basic ways how you could handle it - there are certainly more ? Hope that gives you some ideas.

Thanks @Mike Rockett for the help ~ I'll take a look at the mapping collections and use the existing solution for query strings.

Hi bernhard / teppo, Can it really be that simple? Thanks for the very prompt replies and good advice ?

You go away for a minute and this is what happens...? TL;DR From Device-centric to App-centric development: ambient computing Dart and Flutter ranked #1 and #2 for fastest-growing language and open source project respectively over the last twelve months - GitHub’s 2019 State of the Octoverse report. Flutter is now one of the ten most starred software repos on GitHub. Flutter described as “the fastest-growing skill among software engineers”. LinkedIn, 2019. Flutter for web is in beta. Flutter for desktop is in alpha for mac-OS. You can edit Flutter code, run it and view the rendered UI online in DartPad. See the samples drop-down on the top-right. Adobe XD, Supernova, etc: flutter plugins. Full announcement here. Videos here (Flutter Interact 2019).

Hi @alexpad, You can do it with adding inline css rules like style="background-image: url("<?php $slide->yourImageField->url; ?>") " Gideon

ProcessWire 3.0.123 and PHP 7.2 play really nice together out of the box. An update or upgrade of ProcessWire therefore isn't needed actually. The downtime you experience might be another issue... either cached pages, a bunch of cached compiled files and modules... are there any errors in the frontend or in the logs (Setup > Logs) you could share with us? Is only the frontend or even the backend/admin area affected by those issues? Or maybe even better a link to your site. Oh... welcome to the best community in the world. ?

Hi guys, thx alot for the discussion ? Good point. I think that should not be a problem. If there is an issue with the core, it should be easier to check a simple fix than to fix the issue yourself. If it was a complicated fix, this module might not be the right place for it. I've added @adrian as collaborator on the Repo - the goal is that this project is a "real" little community project ? --- Thx adrian, I've updated the description of the module: --- Actually I think it IS a module for the average user. See https://github.com/processwire/processwire-issues/issues/812 for example. This is a CSS issue that any webdeveloper can easily fix by some CSS rules. The only problem is: How to get the code properly into processwire. There are several possibilities: Overwrite the core css file (easy, but no option, of course) Create a PR (you don't know when it get's merged and you need a workaround until then) Use a module like Admin Custom Files (this works for CSS and JS, but this will not work if you need hooks for your fix) Add your fix via hooks in ready.php (you end up with a mess of hooks in ready.php and you need to copy over code snippets from project to project) Create a module for it (that might be too much effort for most users for simple fixes) The module makes it really easy to apply any kind of quickfix. And it makes it really easy to merge those fixes via PR's (for the ones maintaining this module). --- True! Nothing to add ? --- It's not intended for hacks, it's intended to fix issues that one would report in the PW issues repository until the issue get's fixed there properly. Hope that makes sense ? Thx, that's a good idea, thx ? --- Nice idea. I'm not sure how helpful automatic statistics would be though. I've got bad feedback on my modules implementing google analytics download tracking and numbers where small overall anyhow, so I'm really not sure how much help a "this fix was used 5 times since 08/2019" would be ? What do you think of a obligatory property for every fix that links to the related PW issue report. This would make sure that the issue is reported in the issues repo, seen by Ryan and users can vote for the issue there (give a thumbs up). That would also have the benefit that users can raise their voice there, comment things, add screenshots etc.; A lot better than some strange number where nobody knows what it shows exactly... --- Could you please try to do that on your own? I've added you as collaborator ? --- Thx again for all your contributions! Have a great week.

IMHO... I see your concern and fear here but... this module isn't for the average user as they aren't that deep into the core details of ProcessWire. Mentioning an issue is easy, reporting an issue is work, fixing an issue with this module is art.

Hey @bernhard - you've probably already seen this comment via Github, but I'll repost here for others. I like your proactive approach with module, but I fear that it might actually slow down fixing these things in the core because if users start adopting it, they'll be less likely to add their voice to the actual issue reports and so Ryan won't see that the issue affects other users as well. I hope I am wrong though and I really do appreciate your effort!

Yeah, the idea is to have a shared place where we can apply those fixes and do not have to wait for core fixes. The benefit compared to placing hooks into /site/ready.php is that we can share our code, it's easier to test in different environments and we can provide better suggestions for a fix to ryan. PS: Happy 1000 @wbmnfktr ?

@Sevarf2 thanks for giving it a try. I'll try to reproduce your error in the next days, maybe I can find a solution. sorry for your troubles.

Just verified that this can be made running in combination with @BitPoet's simple language switcher: I've basically added a text field url_domain to the language template and moved the default language detection from _init.php into the updatePath method (so my loop makes much more sense now): public function updatePath($path) { $httpHost = $this->wire('config')->httpHost; $languages = $this->wire('languages'); // Setup default language by domain root foreach($languages as $lang) { if(($lang->url_domain != "") && (strpos($httpHost, $lang->url_domain) > 0)) { $this->user->language = $lang; break; } } This change eliminates most of the other default processing, since the default already set based on the domain name. Throughout the site I'm using localUrl to generate internal link urls, that code was changed to get rid of the language segment in case it is the default for the current domain: public function hookPageLocalUrl(HookEvent $event) { $lang = $this->getLanguage($event->arguments(0)); $config = $this->wire('config'); if(($lang->url_domain != "") && (strpos($config->httpHost, $lang->url_domain) > 0)) // Default for this domain? $event->return = $config->urls->root . ltrim($event->object->path, "/"); else $event->return = $config->urls->root . ltrim($lang->name . $event->object->path, "/"); } The benefit of this is, that languages can be added to the site without the need having an associated domain for each. And it does not break old links on my site, which still have the language in the url. So www.domain.com/pagename and www.domain.de/en/pagename still retrieve the same content and another language may be reached through www.domain.de/fr/pagename or www.domain.com/fr/pagename for example. Edit: Just in case someone wants to see this in action: www.versus-x.com (english) www.versus-x.de (german) www.versus-x.com/de/ (also german) www.versus-x.com/fr/ (french, incomplete, for testing only) www.versus-x.de/fr/ (french, only parts as well)

Just in case someone else arrives in this thread, this is now implemented in Batch Child Editor: https://processwire.com/talk/topic/6102-batch-child-editor/?do=findComment&comment=149975

Sure. Thanks for helping me The module is here Extract it to site/modules and then install both modules in PW. Here is the code I use to render the comments and the form on the frontend: <div class="row"> <?php $commentnumber = 0; foreach ($page->commentsrating as $comment) { if ($comment->status < 1) continue; // skip unapproved or spam comments // if ($comment->status < 1 || $commentnumber >= 3) continue; // skip unapproved or spam comments $commentnumber++; $cite = htmlentities($comment->cite); // make sure output is entity encoded $text = htmlentities($comment->text); $title = htmlentities($comment->title); $rating = htmlentities($comment->rating); $date = date('d/m/Y g:ia', $comment->created); // format the date echo " <div class=\"review\" itemscope itemtype=\"http://schema.org/Review\">"; echo "\n\t<div class='rating' itemprop='reviewRating' itemscope itemtype='http://schema.org/Rating'>"; echo " <span itemprop='ratingValue'>$rating</span><span class='fa fa-star star selected'></span><span class='fa fa-star star selected'></span><span class='fa fa-star star selected'></span><span class='fa fa-star star selected'></span>"; echo "\n\t\t<span itemprop='author' itemscope itemtype='http://schema.org/Person'><span itemprop='name'>$comment->cite</span>"; echo "\n\t</span>"; echo "</div>"; echo "<span itemprop='reviewBody'>"; echo "<strong class='title'>$title</strong>"; echo "<em>$comment->text</em>"; echo "</span>"; echo "</div>"; } ?> </div> <div class="text-centered"> <button class="btn" id="showcomments"><i class="fa fa-comment"></i> Kommentieren</button> </div> <?php echo $page->commentsrating->renderForm(array( 'headline' => "<h3>Sag uns deine Meinung</h3>", 'successMessage' => "<p class='success'>Danke. Dein Kommentar erscheint, sobald wir ihn freigegeben haben.</p>", 'pendingMessage' => "<p class='success'>Danke. Dein Kommentar erscheint, sobald wir ihn freigegeben haben.</p>", 'errorMessage' => "<p class='error'>Dein Kommentar konnte nicht gespeichert werden. Bitte überprüfe, ob du alle Felder korrekt ausgefüllt hast, bevor du es erneut probierst.</p>", 'processInput' => true, 'encoding' => 'UTF-8', 'attrs' => array( 'id' => 'CommentForm', 'action' => './', 'method' => 'post', 'class' => '', 'rows' => 5, 'cols' => 50, ), 'labels' => array( 'cite' => 'Dein Name', 'title' => 'Titel', 'email' => 'Deine E-Mail', 'text' => 'Deine Meinung', 'submit' => 'Abschicken', ), // the name of a field that must be set (and have any non-blank value), typically set in Javascript to keep out spammers // to use it, YOU must set this with a <input hidden> field from your own javascript, somewhere in the form 'requireSecurityField' => '', // not used by default )); ?>