bernhard

Just updated all the dependencies of this module to the newest versions: Package operations: 0 installs, 4 updates, 0 removals - Updating myclabs/deep-copy (1.7.0 => 1.9.5): Downloading (100%) - Updating paragonie/random_compat (v2.0.12 => v9.99.99): Downloading (100%) - Updating psr/log (1.0.2 => 1.1.2): Downloading (100%) - Updating mpdf/mpdf (v7.1.0 => v7.1.9): Downloading (100%) v1.0.2

Nice! Didn't know that! Always happy to hear about other options that I might not know, thx! ?

It sounds like output formatting is OFF when the data of the image is requested, therefore pw treats the data of the field as PageImagesARRAY. That's why you have to get the first item manually. This step is done automatically when output formatting is ON and your field is set to single image.

It has been quiet here, but I'm using RockMigrations on a daily basis. It can also be handy during site development, eg today I had to refactor my setup (change some fields, delete them, create new fields instead). I only have test data on this site, so when I want to delete a field, I really don't care about losing data... PW asks a lot of questions before removing a field from the system (which is good in 90% of the cases), but for me it is often a burden. RockMigrations + TracyDebugger to the rescue: $rm = $modules->get('RockMigrations'); $rm->deleteField('location'); Manually one would have to remove the field from the templates first, confirm that one might lose data etc.; Too much clicking imho ?

$(document).on('repeateradd', function() { alert('added'); }); https://github.com/processwire/processwire/blob/master/wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.js#L330

Hi @daiquiri , welcome to PW and the forum! You got 2 answers of long-time members and even 1 script that you can use within 3 hours. There's no need to take anything personal ? Reality is something in our heads ? The reality is that the changes you are asking for are not a simple task for PW. PW works totally different than other cms's - so it's quite logical that what might be a simple task in other systems can be quite hard in PW, and vice versa. Many of us here love PW for many things, but there are also drawbacks and things that are not so easy, and it looks like you just found one of these things ? But often when working with PW and especially coming from other systems there are other ways that you haven't thought of before. That's because your reality is based on the experiences you got from other systems. And that's what @Macrura said with this statement: Call the root page of a PW instance sacred or call it something else - there might be an easier way to achieve what you want in the end...

I've added a hooks folder where all daterange hooks can be put into: All hooks can be disabled in the module config: Not sure if that makes sense at all, but it was fun to build ?

Hi @teppo that's a very good point and a reminder, that adding rrule support might be overkill for this module. Maybe it would make more sense to have this in a separate module! Just implemented a little funktion that can list items before and after a given date: The nice thing is that you can specify multiple templates. The idea is to show events in the footer and there it might make sense to show also events of the near past ? Past events are sorted by end date, future events are sorted by start date. Quite nice and quite easy to query: Not sure where to put this though. Right now it's a hook in ready.php - but there it is not reusable. I thought of adding this to every RockDaterange object, but it feels wrong. Maybe adding a helper module for such features would make sense? Actually the wording of this method should be findBeforeAndAfter instead of GET... I'll change that!

I'd call them something like 'Input time' and 'Input end' because that is actually what you can do after clicking on them and is also like an instruction of what to do or what can be done. That sounds good, thx ? Yeah. There are some complicated things involved when displaying events... What if the user visited the List on March 14th? And how to do proper limit and pagination queries? Eg find exactly 12 events but show recurring only once... Not sure how one would solve that properly ? Thx everybody for the feedback. I'll read the recurme thread that I followed only loosely and finish my current project with the basic implementation of RockDaterange (without RRULE). We'll see how that goes and what might be added in the future...

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;

Could you please be more specific on this? Yeah, it's icons with hover text (title attribute) - but the screenshot program closes the tooltip before it takes the screenshot... Actually it doesn't matter too much if it's icons or text - what is really different now is that I changed the name of the first checkbox from "fullday" to "hasTime". This is now consistent with the second checkbox named "hasEnd" and it is more intuitive for the user I think. Check the checkbox = show time inputs, uncheck = don't show time inputs. Before it was the other way round: Checkbox checked meant fullday, meaning that the time input was hidden. The second checkbox worked the other way round: Checked = show inputs, unchecked = hide inputs. I'm happy to get suggestions how to call those two checkboxes... Show time input? Show end input?

Other handy selectors added ? Any other ideas that could be necessary or helpful? It's really easy to add others ? // returns all pages with a date in a specified year case 'inYear': // split value by semicolon $str = $this->getFromToStrings($value, 'year'); $query->where("{$table}.data<='{$str->to}'"); $query->where("{$table}.end>='{$str->from}'"); break; // returns all pages that start before a given date case 'startsBefore': // split value by semicolon $str = $this->getDatestring($value); $query->where("{$table}.data<'$str'"); break; Current options: inRange onDay inMonth inYear startsBefore endsBefore startsAfter endsAfter

Little improvements to the input: 1) Checkboxes do now show an icon. I think that's a lot more intuitive! 2) You can input dates and times using the "comma" keyboard key (both regular comma and the numblock comma). This is convenient for german keyboards that have a comma instead of a dot right beside the 0 digit): I also did quite some refactoring and changed the db schema so that the data column holds the timestamp of the first second of the timerange. This makes it possible to choose the range field as sort option in the template settings.

Brilliant, thx for this module! ? The sort order must be specified on the PARENT page, then all children get sorted. My setup: news (template "news") - news1 (template "newsitem") - news2 (template "newsitem") ... Then i set the sort to the "range" field (a timestamp of the first second of this day) and also created, so that pages that where created later are listed on top: news: -range, -created

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).

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 ?

I've absolutely no experience in handling different timezones, so I'd be happy to get a quickstart or a good read for that topic ?

@gebeer and anyone else interested please join the discussion here:

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.

Got it working by adding a custom class via the beforeShow function: // show time pickers $(document).on("focus", ".RockDaterange .time", function() { $(this).timepicker({ timeFormat: 'HH:mm', dynamic: true, timeOnly: true, showTime: false, beforeShow: function(el, obj) { $(obj.dpDiv).addClass('RockDaterange'); }, }); }); .ui-datepicker.RockDaterange .ui-timepicker-div { border-top: 0; margin-top: 0; } .ui-datepicker.RockDaterange .ui-widget-header { display: none; } .ui-datepicker.RockDaterange dl { margin: 0; } ? PS: Here are the datepicker docs: https://api.jqueryui.com/datepicker/#option-beforeShow

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/

Thx, I'm done with my testing - asking earlier would have saved me some hundred clicks ? ? $options[Dumper::COLLAPSE] = 14; $options[Dumper::COLLAPSE_COUNT] = 7; This worked well. It would be nice to have an option somewhere for this, but it is definitely not high priority, so don't hurry. Thx anyhow for taking it into account! ?

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

Hey @adrian just using the tracy console a lot gain for testing/developing a module. It's absolutely brilliant! Thx again! Do you have an idea of a quick solution for having dumped objects always unfolded? This is what I'm doing: I always have to unfold the object dump to see the results. For that I have to use the mouse - which is slow and tedious. If there where a checkbox "automatically unfold all dumps" it would speed up my process even more. Looking forward to hearing your thoughts about this, thx. Maybe there is already an option somehwere?

Would be very interested to get some details on this! ?