Leaderboard

@MarkE I was going to say "+1 for the times feature" but for accommodation it doesn't make as much sense to have it there as you are mainly after the number of days/nights right? Arrival/departure times could simply be set against each holiday cottage/apartment or fall back to a "company standard" arrival/departure time like you get with some of the bigger companies? All I'm thinking is otherwise you need to enter the arrival and departure time *every time* rather than have it set at one of the "parent levels" like cottage/apartment or globally. @ryan I definitely see the point for an optional time input for some types of event - like a single day course that runs 11am-3pm it would be good to still use this field otherwise you're back to needing 2 fields again. Same for multi-day events where there's a very definite start and end time. These are the sorts of things where on the frontend you would have a calendar with all the events on and there would be a real mix of single/multi-day but you definitely want a way of showing the times. Also allows for frontend stuff like the Resource Timeline and Resource Time Grid on libraries like https://fullcalendar.io/demos

This week in the blog we'll take a detailed look at the newest addition to the ProFields set of modules: the Date Range Fieldtype and Inputfield. This post serves both as an introduction to, and documentation for this new module. In addition, the v1 (beta) release of the module is now available for download in the ProFields board. https://processwire.com/blog/posts/date-range-fields/

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!

@bernhard, thanks for the heads-up. The new tab option was working for child items but not for the top level menu items. Fixed in v0.1.5 and in this version I've also added an option to define an icon for the top-level items - these are only visible in the sidebar menu so probably not seen all that often but still good to have control over.

With my system, the times are filled in automatically from the default for the property or system, but can be changed if, for example, early access is granted. Since the system also generates email correspondence with the guests, it needs to tell them the arrival and departure times. Sure, it could be done with separate fields, as it is now. Having thought about it a bit more, I can see that there might be some complications arising from including times in the range and you would certainly want it to be hidden in some circumstances. I have another app with event booking, where date and time are essential. Using the current interface, similar to the one in my example, is a bit fiddly.

Hey @Robin S thx for the helpful module. Used it today for the first time and unfortunately the "open in new tab" checkbox has no effect. I didn't find any occurences of "target" or "_blank" in the module's code, so I think it's missing ?

Yes this is what I was doing... but turns out I had a typo and it was loading my 404 page in the panel I think. This is why I was getting the nav bar showing ?. The panels now work exactly as expected (and as you describe) to load my module functionality! ?

You'll have to write some code for that @ShadowByte. This is my code for my blog tags (in Latte) which I'm sure you can adapt for your purposes (my blogs are in a repeater matix field here): {var $blogsPage = $page->motif_display_pageref} {var $blogs = $blogsPage->find("template=MotifDisplay, parent=$blogsPage")} {var $tags = []} {foreach $blogs as $blog} {foreach $blog->motif_layout_components as $component} {if $component->type == 'blog-post'} {var $blogTags = $component->motif_blog_tag->explode('title')} {* {bd($blogTags, 'blogtags')}*} {foreach $blogTags as $blogTag} {if !array_key_exists($blogTag, $tags)} {do $tags[$blogTag]['name'] = $blogTag} {do $tags[$blogTag]['count'] = 0} {/if} {do $tags[$blogTag]['count'] += 1} {/foreach} {/if} {/foreach} {/foreach} {* Sort the tags in descending order of frequency so that the most used are at the top *} {var $tagCount = []} {foreach $tags as $key => $tag } {do $tagCount[$key] = $tag['count']} {/foreach} {do array_multisort($tagCount, SORT_DESC, $tags)} {*<section>*} <ul n:foreach="$tags as $tagKey => $arr"> <li> <a href="{$blogsPage->url . 'tag/' . $tagKey}">{$tagKey}</a> </li> </ul> {*</section>*}

Hi Robin, actually this solves the issue nicely going forward. Thank you.

Hi @brodiefarrelloates Could it come from an outdated module? What says the stack trace? (should be in errors log) In my PW database I don't have any "sessions" table, only a session_login_throttle. EDIT: OK I see it comes from wire\modules\Session\SessionHandlerDB\SessionHandlerDB.module. I have no idea when this module is triggered but you can see in source code the SQL query to create "sessions" table: public function ___install() { $table = self::dbTableName; $charset = $this->wire()->config->dbCharset; $sql = "CREATE TABLE `$table` (" . "id CHAR(32) NOT NULL, " . "user_id INT UNSIGNED NOT NULL, " . "pages_id INT UNSIGNED NOT NULL, " . "data MEDIUMTEXT NOT NULL, " . "ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, " . "ip INT UNSIGNED NOT NULL DEFAULT 0, " . "ua VARCHAR(250) NOT NULL DEFAULT '', " . "PRIMARY KEY (id), " . "INDEX (pages_id), " . "INDEX (user_id), " . "INDEX (ts) " . ") ENGINE=InnoDB DEFAULT CHARSET=$charset"; $this->database->query($sql); }

I’ve never worked with panels (just yet) but from what I’m seeing if you have a view ready in your Process module, say “__executeSomething()”, isn’t it just a matter of having a link pointing to that view? <a href="/something/" class="pw-panel">Open in panel</a>

With the style panel, you can customise the look of your website without writing CSS code. If you prefer to work with code, that's fine too. Just deactivate the panel and load your CSS as you are used to. PAGEGRID will stay out of your way. You can also combine the approaches or bring your favorite CSS framework. The style panel is a tool for developers, designers or "advanced users", not necessarily for your client (you can give them access, but I wouldn't recommend it ?). The great thing about using the style panel (and PAGEGRID) is that you don't need a build tool or deticated development environment. If you use the block modules, a simple database backup can be enough to restore all changes. Since the templates and fields are all created by the modules, migrations are no longer an issue. This can be a quick and easy way to create a custom website. Which CSS frameworks are supported by PAGEGRID? The style panel generates modern vanilla CSS. The block modules use vanilla CSS and vanilla JS. With your own custom blocks you can easily add a framework if you want. If there are enough requests in the PW community for a certain framework, I might build some blocks for it. ?

That's possibly a browser cache issue, because the variation filename doesn't change when the quality option changes. This problem is the motivation behind this module: https://processwire.com/modules/unique-image-variations/

Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.

Hi @JoseFrasherunfortunately not. As PW is so perfect and fast on all frontend issues, it is a bit tricky on the user generated content. So I still use the API as above to create the new content. Then I list the newly created page in the template called "my-pages": foreach( wire("pages")->find("created_users_id=$user->id, template=user-generated-content-template") as $item){ ... <div class="btn btn_default" <?= alfred($item, "title,body,.....") ?>> <i class="fa-solid fa-pen-to-square"></i> Edit </div> } And one problem is still remaining: Users can edit other templates of "user-generated-content-template" created by other users as well, if they know how to. Here I should add somewhere a hook on this template for edit, if the current user is equal to the user, who created that page.