Leaderboard

I've been using Apache forever... never even touched nginx. Today I felt like giving Caddy a try and it feels nice. I developed what I believe is a much more improved Caddyfile that also supports ProCache and stronger blocking of files (returns a 403 like PW's htaccess file, instead of a 404 which is what /denyaccess seems to do). I added a way to also put the site in maintenance mode (meaning all requests get rewritten to /maintenance.php) if /maintenance.php exists (which is now part of my deployment process). Hopefully I can share the results in a week.

?

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/

I tried all of the suggestions. But none of them seem to work. Thanks bernhard for the hint on how to help "myself". I will try to formulate what I am trying to do. So I have a website, that has 4 language versions. Default is czech. Right now, I am trying to translate all the new labels and what-not to the 4 languages. I am using a page with template term-translations . In this page are fields(Multi-language) that contain different phrases which I just inject into HTML code. The problem is that I have to set a label of a button to submit and reset a registration form, but these buttons are added into the form in the LoginRegister module. That is what I am trying to do. I am already using the multi-language system from PW, but now I hit a wall. (As you can see on the image below) Thank you for trying to help me. I am new to PW ? Krit

Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

Big thanks to all of you! I simply used the $page->delete() in a template file like this: // Find old pages $pages = $pages->find("template=mytemplate, parent=myparent, sort=date, limit=50000"); // Delete old pages foreach ($pages as $page){ $page->delete(); };

Seem I lost the overview of all your rockstar modules and snippets ?. Anyway keep on rocking. There is almost all times a useful RockX which fits your needs or solves a problem for you.

By bootstrapping Processwire via external PHP script and execute it via console or web browser. Some infos can be found in this topic https://processwire.com/docs/front-end/include/. Another option may be RockMigrations from Bernhard https://processwire.com/modules/rock-migrations/.

@adrian – I've released 1.5.64 which adds the safety net around CLI usage (as a general rule) and request_uri. Please let me know if that solves it.

Guessing this should do the trick…?

@gornycreative sure - thanks! Basically i'm only using YT Pro for the styling, and for modeling the basis of certain types of content/markup. Using the local install of WordPress+YTPro I could setup the preferences for the look and feel of the site, choose the theme, etc. I can sync the YTPro generated CSS file, JS and fonts across to the theme folder in my PW folder. I have a MarkupThemeEngine module that handles frontend theme stuff. It has an api that simplifies handling of display assets (CSS/JS). A fair amount of the markup is custom coded, textbook UIKit - but that markup inherits the styling of the YTPro generated CSS file. The reason i can't use WordPress is that it ends up being too much work for the users, and it doesn't meet our requirements for a lot of content types. Many things that need plugins in WP can be easily created in PW with some small effort. The template files are designed to make decisions and do all of the heavy lifting, creating intelligent processes that assist the users to get things done fast. The backend config for any given page is mostly text, images and preferences – nobody has to actually design or configure anything in the admin. Fairly complex pages with multiple sections, images, audio, and video can be setup and done in a matter of minutes. (If i needed to create a more complex layout, I might go and do it in my WordPress install and then analyze the output code and turn that into an algorithmic setup in PW). There are not that many templates - Basic Page and a Page Builder, plus the custom ones for Albums, Events and Players. The Page Builder template uses a PageTable - each section of any Page Builder page is stacked "sections"; to add a section is just an entry in the PageTable; and then you select the "Section Type". At that point there may be a couple of things to populate - image, text, and some preferences. There is a centralized Media Library, and a Media Select field that uses InputfieldSelectize to choose any item in the media library.

This week the core dev branch version has been bumped to 3.0.231. There are about 15 commits in this version relative to the previous. In the dev branch commit log you'll find a good mix of issue fixes and improvements. If you are already using the dev branch, this version is worth the upgrade. If using the main/master branch then it should be a safe upgrade as well, though none of the updates are urgent. And it won't be long till they are also merged to the main/master branch soon too. This week I've also been working on 2 new related modules: FieldtypeDateRange and InputfieldDateRange. These modules allow selection of starting and ending dates to support a date range. It also calculates and stores the number of days and nights for querying and sorting purposes. The "date from" and "date to" can be independently queried from $pages->find(), as can the days or nights. The InputfieldDateRange module can be used independently of its companion Fieldtype module, making it possible to use the date range Inputfield in FormBuilder or other Inputfield forms. One context where the Inputfield might be useful is when selecting travel dates on a front-end form, such as one from FormBuilder. When used as a Fieldtype, you might use it to specify availability of something, start and end dates to publish content, event dates, or any number of other use cases. Below is a screenshot of the Inputfield as well as its configuration tab. The JS-based input widget comes from an existing package that I've made some modifications to, and it works really nicely, with a polished and easy-to-use UI. I originally found it booking some travel online, and really liked the way it worked. I was able to track it down on GitHub here and thought it would be useful to build an Inputfield module around it. It can be set up to work like the core date picker where it appears when you focus in the input, or it can be configured "inline" where it is alway s visible (and the related text input is hidden). In the following screenshot, I've specified that Sundays can't be used for start/end selections and that November 23 is not available. The selected range spans two months. If you want it to span more months, you could click the right arrow in the December calendar to find your desired month, leaving the first calendar in November. In this manner, you can select ranges that span multiple months, or even years: Here's the Inputfield configuration screen so far. All of these settings are hookable as well, as some of them are more likely to be useful dynamically, especially min/max start and end dates, non-selectable dates, etc. (Note the screenshot below does not necessarily reflect the settings in the screenshots above). More on this next week. Have a great weekend!

Hey @ryan that looks great! Are you also planning to add an API to select pages matching a date range? That would be great, because when working with date ranges the INPUT is only one part of the equation. May I ask you to have a look at this thread? https://processwire.com/talk/topic/23097-previewdiscussion-rockdaterange-fieldtype-inputfield-to-easily-pick-daterange-or-timerange/ It shows what I came up with some time ago. I didn't proceed with the module, but some parts of selecting pages where quite promising: <?php // find events in 2023 (meaning from 2023-01-01 00:00:00 to 2023-12-31 23:59:59) $pages->find("template=event, my_range=2023"); // find events in taking place in 2023-11 (meaning from 2023-11-01 00:00:00 to 2023-11-30 23:59:59) // this would also find an event starting in 2023-10 lasting to 2023-12 $pages->find("template=event, my_range=2023-11"); // find events in taking place in 2023-11-17 (meaning from 2023-11-17 00:00:00 to 2023-11-17 23:59:59) $pages->find("template=event, my_range=2023-11-17"); // find events starting after 2023-11-17 00:00:00 $pages->find("template=event, my_range.starts >= 2023-11-17"); // find events ending before 2023-11-17 00:00:00 $pages->find("template=event, my_range.ends < 2023-11-17"); Not sure how/if that works when dealing with different timezones, but for my use case it was of great help to have this easy human readable API, because when using timestamps it quickly get's complicated and prone to errors (like forgetting to use <= instead of < or such): <?php // find events taking place in 2023-11 $from = strtotime("2023-11-01"); $to = strtotime("2023-12-01"); $pages->find("template=event, my_range.starts >= $from, my_range.ends < $to"); That example is actually not working, because for real world queries you'd need to take more possibilities into account: So if 2023-11 starts at the first black line and ends at the second, then you'd need this query to find events that take place in 2023-11: // find events that either // start within 2023-11 (meaning start after or at 2023-11-01 00:00:00 and start before 2023-12-01 00:00:00) // or end within 2023-11 (meaning end after or at 2023-11-01 00:00:00 and end before 2023-12-01 00:00:00) // or start before 2023-11-01 00:00:00 and end after or at 2023-12-01 00:00:00 That shows that it quickly gets very complicated and you need to be really careful with all the times and comparison operators! IMHO using the other syntax makes code a lot easier to read and maintain. For my use case (showing events in a calendar) it was a lot easier to use this syntax, because you don't have to find the timestamps of the first second of the month and the last second of the month or the first second of the next month etc.; You just use "range=2023-11" and that's it.

@kongondo Is there more to see in the meantime? ?

Hi xfroggy, Just had this same problem and resolved it by setting the sessions path in config.php to /tmp: $config->paths->sessions = '/tmp'; Hope this helps.