Leaderboard

This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/

Just realized that mPDF version maximum was set to 7.x - RockPdf 2.0.0 uses mPDF library v8.0.5 and might introduce some breaking changes - so be careful with the update or just use RockPdf <= 1.0.2 Updating dependencies (including require-dev) Package operations: 0 installs, 2 updates, 0 removals - Updating setasign/fpdi (1.6.2 => v2.3.0): Downloading (100%) - Updating mpdf/mpdf (v7.1.9 => v8.0.5): Downloading (100%) v2.0.0

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.

Interesting Tool => Code Snippets Manager { https://masscode.io/ }

What I know has been pieced together from official docs and discovered through trial and error, so I can't provide a good link there. However, I've pushed a few pieces into a small module based on Memache that can be a (partial) stand in for WireCache as an example. You can find it on github as PwMemcache. It has just a few methods to set/get/delete cache entries and doesn't allow saving and restoring of full pages like WireCache does, but it does have a renderFile method similar to WireCache. Maybe that could be a starting point. Most of the magic in using memory caches is using well thought out cache keys to avoid conflicting names (you're likely to use them more intensively than database caching) using reasonable expiry values (same as with database caches) preventing outdated data (e.g. by deleting entries when pages are changed, there's little 'automatic magic' there) taking care of special considerations when data is serialized and later unserialized, since behavior differs between solutions How exactly that best goes depends on the features of the caching solution. Unlike WireCache, many in-memory solutions have no wildcard deletion operators, so you sometimes have to build workarounds. My module for example does this when you pass PwMemcache::expireSave to the renderFile method. The cache contains an extra array where all the entries are stored that have to be cleared when a page is saved. In a Pages::saved hook, this entry is read, all cache entries listed in the array are deleted and the entry is emptied.

Hi, With the deprecation of Instagram's API and therefore the end of the Instagram Feed module, I've developed a replacement module which uses the Instagram Basic Display API: https://github.com/nbcommunication/InstagramBasicDisplayApi To use this module you'll need: ProcessWire >= 2.7 A Facebook Developer account Access to the Instagram user account you wish to use Prior to installation, you'll need to create a Facebook app. The app you will create uses the User Token Generator for authentication - it does not need to be submitted for App Review (and therefore stays in Development mode). The README contains full instructions on how to create and set up the app and also how to use the module. The primary reason for this module's development was to retain functionality on existing websites that use the Instagram Feed module. To assist with upgrading, this module replicates some methods provided by Instagram Feed. I've already upgraded a couple of sites and it was quick and painless ? Cheers, Chris

I usually supplied "translation keys" instead of the default translation to translation functions, and translated them in all languages, eg. __('btn_submit') instead of __('Submit'). This way they rarely needed to be changed, only when the translation changed to something completely different.

Or just set the title and leave PW to take care of the name automatically.

@cosmicsafari Well, you could take a look at the BCE module... Did you look at server logs? Did you also try with a very small CSV file - maybe it's not the size of the files, or the time it takes to process everything, but some stumbling blocks in your code ? I would first try it with adding output formatting set to false, and then also use sanitizers (you can never trust user input), or at least trim(). I also noticed this line $p->name = $name.'('.$lat.','.$lng.')'; which doesn't look OK. PW page names can't have special characters like (). Use the page-name $sanitizer and get rid of the () (or any other non-allowed characters).

I've dabbled a bit and adapted my cache module to work with Redis (working mostly on Windows, this was a bit of an adventure, but Windows Subsystem For Linux saved the day). CacheRedis - a simple Redis cache interface for ProcessWire There should be enough documentation to get started in the README. In short, it has the following methods: $redis->fetch($key[, $expire, $func]) $redis->store($key, $expire, $value) $redis->delete($key) $redis->flush() $redis->renderFile($file[, $expire[, $options]])

Hi, I've updated this module with a lot of progress - still should be considered alpha, but should be ready for production soon. Cheers, Chris

Do you have a namespace declaration in your template?

The biggest hurdle of timezones is actually in handling "the future". Timezone rules are in constant fluctuation (be it error corrections or actual changes the IANA timezone database changes a few times a year: https://www.iana.org/time-zones). One prominent example is the EU right now, where DST was ruled to be eliminated in the near future giving each country the option to choose if they want to stay on DST or non-DST offset. Therefore to store a point in time (in the future) you at best store not just a datetime/timestamp, but a timestamp as well as the source timezone and used offset. This allows you to detect if the offset of a timezone did change between the time is was stored to the db until the time of retrieval. Otherwise changes in timezone definition might lead to incorrect results (someone being at a place at 11:00 when the time was supposed to be 10:00 wall time). This blog has a few posts on the topic, even if they're not in php: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html Edit: You can ignore changes in timezone definition by storing datetimes in their source timezone, but this won't let you easily compare multiple values in the db. I've some more interesting things on the topic to share. If you're working with intervals I highly suggest using Allen's Interval Algebra as well as watch this talk by Eric Evans:

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

When you know your I.P. maybe you could check against that. One hook you could use is session::allowLogin

Hi @astock, ok. I think then something is not working as expected, and I cannot help any further here, as I never used this module. Maybe we can ping @Soma, or we need the help of someone who already used this. What is the PW version you are using?

@Sergio sorry about that, 4K screen ?

Well said @LostKobrakai! Agreed 100% IMHO that depends a lot on your skills. For me it took very long to understand how the backend works and what all those (process)modules do and how all this plays together. That's why I wrote my tutorial blog post (which by the way took also very long, so I perfectly understand that ryan does not have this time - especially if it is correct that CMF users are not the target audience (and that's what I meant in my short statement above where I said that I think that ryan does not really care). And even if you are highly skilled it would be a lot more efficient to read good docs than to read good code. I liked to read @Robin S answer and I'm sure it was not meant bad ? I agree with you that it would be a lot easier if we had proper tutorials (not just api docs and example modules) about all the backend stuff. I've mentioned several times that I think that the community management and teamwork on the project could be improved. It feels like ryan does all the work and if he has no time for something, it's just not done... On the other hand writing my guest blog post was easy: I just asked ryan if he was interested and I got a login and started writing... It's for sure not a perfect documentation about the backend, but it's a first step and I invite others to follow ?

Looks very cool, @ukyo! Thanks for that, but the font-size on the video was hard on my eyes. ?