pideluxe

Thank you very much for taking on this topic, as it is often needed and a reasonable and simple implementation is important. What do you think about including a duration in the field? If you were to use the data from this field for a calendar, it would be good if the duration was also stored immediately. I found out that php-rrule doesn't directly take duration into account, but there is a issue for this. I've already made some changes to include the duration in your fieldtype, but this is more project-specific and one would have to think about how to implement this in general.

I'm now at 1 1/2 hour from the laravel video and he's still copying database entries to php-files to import it... I think the videos should be split into (short) comparisons to other frameworks/cms and an introduction (longer) to processwire. That way, users of other systems could be attracted to watch the introduction. For the comparisons, it would be great to have experts from other systems doing the same things someone does with processwire. But one could also take videos like that one from laravel and do the same in processwire.

You could also add the parent element as first element in the sub nav. The processwire website does it also this way.

According to their trello board for new suggestions: Project must have >5k stars on GitHub or equivalent The star count for processwire is currently under 700, so this is a long way to get there.

Have a look at the API docs for the $datetime variable (https://processwire.com/api/ref/wire-date-time/). Just insert the date form PW page as argument and convert it to the format you like.

From the recent discussion about the roadmap & wishlist for 2021 and some other posts by @ryan, it comes to my mind that developing and coordinating the whole project for one person is becoming harder and harder and leads nearly to the reverse of expanding the ProcessWire ecoysystem. This is not against Ryan, i think everyone here knows how engaged he is about ProcessWire, but he has only 24/7 (sometimes i think he's got far more than that...). We as the community could support the project (financially) to relieve Ryan and could take over some tasks from him. This could be, but is not limited, to: Building a Foundation/Association/Company to ensure the persistence of the project and to fund the work put in ProcessWire of Ryan (and others). Nearly every other CMSs i checked has something like this (Drupal Association, Typo3 Association, Joomla Foundation, Wordpress Foundation, Contao Association, ...). This also puts more trust in the project, if someone new will check on his engagement in ProcessWire. Assigning persons/teams to work on things: Extending the core (when necessary) Developing and maintaining major modules (e.g. page builder, admin themes, internationalization, marketing, ecommerce system, ...) Testing and inspection of modules developed by others Making translations of modules (translation of the core is mostly covered, i think) Working on PRs & issues submitted on github Working on the homepage Coordinating the community efforts I know, some resorts are already covered by others (e.g. @Pete for the forum, @horst for images, ... ), but there are many other areas where this ist not the case. By joined efforts by the ProcessWire community this hopefully will also attract new developers to the system and by a growing number of users this assists in the things above in a circular process. What do you think?

You could use a masonry-like component, f.e. Filter from UI-Kit (https://getuikit.com/docs/filter). Place the tags from the images in the filter-tags. For creating the filter elements, you could create an array of unique tags and then loop over the array for creating the selectors.

I would also be interested in testing, thanks in advance.

$home = $pages->get('path=/');

I used delayed output and markup regions to make clear, they are just other concepts of templating (engines). Delayed output-strategy is about inheritance and markup regions are the so called blocks in twig. Templating in other languages/engines than php is about using other syntax and replacing php-tags with something else, e.g. {%...%} for twig... And for terms of reusability: If you are using different fields, you cannot reuse your twig-files, or am i missing something here?

Pls tell us, what is the advantage of twig templating over pure php and using the delayed output strategy with markup regions?

Sounds great, thanks for the quick answer!

Is it not possible to use recurme within an Repeater? In Repeater Matrix it works, so it is not a big problem, but for my purpose a repeater would suffice... BTW great module and support, Joshua!

Hey joss, like that little hanna-snippet. But why are you using it in this situation? Would it be not better having a page reference field selecting the tags?

Really nice features! But sounds really not easy to use for everybody right away, maybe it could be a baseplate for theming in pw. Maybe sharing a future version which is less specific would make more sense.