Jump to content

ryan

Administrators
  • Posts

    16,430
  • Joined

  • Last visited

  • Days Won

    1,449

Everything posted by ryan

  1. I hope that you all had a great holiday and New Years. This week on the dev branch is ProcessWire 3.0.234. This version contains 6 issue fixes, but the biggest update (and primary reason for the version bump) is that this version updates to the newest Uikit version in AdminThemeUikit. We hadn't updated it in awhile, so it's a fairly major upgrade. I found that it broke some really minor things and I fixed them as I found them. But please let me know if you come across any other Uikit upgrade issues I've missed. While it is a major Uikit upgrade, it was an easy upgrade thanks to the work of @bernhard and changes he made to the AdminThemeUikit module awhile back. Next week there will be more issue issue fixes as I catch up with the processwire-issues repo. There were a couple issue fixes already in progress this week that didn't make it in to 3.0.234 as I ran out of time, but they'll be committed to the dev branch next week as well. Thanks for reading and have a great weekend!
  2. I'm off work this week, so I don't have any new ProcessWire updates, but just wanted to wish you a Happy New Year! Looking forward to a great 2024!
  3. @JayGee Great! glad to hear you've found the module useful. Thanks.
  4. I think it's a good point, and prior to more recent versions, PW included several site profiles. But by and large the community preferred PW to be slim and not include all the site profiles, so we changed it to just include 1 profile (the minimal blank profile). This is the preference of established users of ProcessWire. But for new users that might not already be familiar with PW, I think having something more for a site profile is preferable. The solution is for PW's installer to be able to download the other profiles automatically if the user wants them. I think this was brought up before, but I haven't done it yet, though perhaps should soon.
  5. The core version has been bumped to 3.0.233 this week. While there aren't a lot of commits, there are some major updates to the core PagesVersions module. I also thought a version bump would be helpful as there's also a new PagesVersionsPro version released which requires features only available in 3.0.233. The PagesVersions module is now pretty much finished in terms of its API and feature set. This week the ability to save and restore partial versions was added, and that was the main remaining thing. By partial versions, I mean the ability to specify what fields are included when a version is saved or restored. Though I think it's primarily useful on the restore side. So if you find you just want to restore one or more particular fields from a past version, rather than all the fields, now you can. The core PageTable field was also updated to support versions, partially anyway. It supports versioning of items already in the page table, but doesn't handle versioning of items that you might add or remove within a version. It turns out it's going to be a lot of work to do that, so I settled with just partial support for this week. As it is, if you add a new item to the PageTable while in a version, then it'll ask you if you want to import it once you edit the live version. If you delete an item, it'll be deleted from all versions. That's how it works temporarily until it fully supports versions. ProFields Table now also supports versions. But there is one case where it doesn't: paginated table fields. A future version of Table will add support for that. Until then, the PagesVersionsPro module does make it clear when a paginated table field won't be added to the version. So now all fields in ProcessWire are supported, except for certain scenarios in PageTable and Table fields. A new version of the PagesVersionsPro module was released as well, and this is posted in the PagesVersionPro support board download thread here. This module made a lot of progress this week and will continue to evolve in the coming weeks. I'll copy/paste the version 2 changelog for it below this post. This weekend or early next week I also plan to release new versions of ProFields Table and Combo. These versions facilitate versions when doing partial save or restore operations that include file or image fields in Table or Combo fields. I hope that you and your family have a wonderful Winter/Christmas/Hanukkah/Festivus holiday! Version 2 changelog for PagesVersionsPro Added the ability to select which fields are included during a restore. When doing a restore, it now detects which fields differ between "live" and "version", making it easier for you to choose which fields to restore. When editing a version the “Delete” tab in the page editor now refers to deleting the version rather than trashing the page. The “compare” option has now been improved so that it can better detect differences between the live and version page. During restore, if you “Choose which fields to restore” you now have the option to compare them individually to see what is different between live and version. Added "page-edit-versions" permission so that you can limit the capabilities of this module to specific user roles.
  6. @Robin S ProcessWire Weekly (weekly.pw) is a great website and I don't want the email to take any of the limelight from Teppo's website. The content is 100% authored by and owned by @teppo, and he's very generous to let us re-publish it in the email. It seems appropriate to me to send the email a week later, ensuring the website remains the primary, most up-to-date source, and the email doesn't take any traffic from it. My hope is that the email increases traffic to the weekly.pw website. The other thing is that the introduction part sometimes refers to the weekend (since that's when it is published), and if I were to send it earlier, the earliest would be on a Monday. So it often reads better to send it on a Friday when any references to the weekend still make sense.
  7. @szabesz Yes. Though it would be a field setting rather than a template one. I suppose field/template context could make it both though. But what I was thinking in addition is that when you choose to create a "new" version, you'd have a "all fields" or "some fields" toggle, and choosing "some fields" would show checkboxes so you could choose the fields. Likewise, when restoring a version, you'd have a similar option to choose what fields get restored. I'm not yet positive it'll be possible, but think it will. The main thing preventing it right now is files, as the version includes all the files in /site/assets/files/123/, and we don't currently have a reliable way to isolate files by field, but I'm working on it. It's not too bad if just considering the core file/image types, but other types can have files too, like Combo, Table, and maybe others I'm not thinking of now. I wasn't specifically thinking of module developers for anything here, and instead just trying to make an API for page versions that's easy to use, similar to other parts of PW. The API would be accessible to anyone developing a site or a module. B
  8. @David Karich Most fieldtypes don't have the version interface implemented, and it's only those that want to override the default implementation that need to do it. But for Fieldtypes that also store data somewhere other than their field_* DB table, they aren't supported unless they implement the interface. The only examples I can think of are Repeater, PageTable and Table (though Repeaters have fully implemented the version interface already). Currently there isn't a way to exclude some fields or types beyond that, but it'll definitely be added as the module matures, likely even next week.
  9. In the last couple of weeks I've been working on the page versions support in ProcessWire (recap here and here). This week the new PagesVersions module was committed to the core. Though please consider it very much "beta" at this stage. Along with this, the core dev branch version was bumped to 3.0.232. The API reference page for PagesVersions is now live here: https://processwire.com/api/ref/pages-versions/. Note that the module is not installed by default, but once running 3.0.232, it can be installed by going in your admin to Modules > Wire > Pages > PagesVersions. In addition, a related development module named PagesVersionsPro has also been released. This module uses the new API from the core PagesVersions module. This module will eventually be merged with or replace ProDrafts. The new PagesVersionsPro support board and module is currently visible to ProDrafts, ProFields and ProDevTools subscribers here. Unlike ProDrafts, PagesVersionsPro gets all of its version abilities from the core, and instead just focuses on providing an interactive interface to them in the page editor. To word it another way, the module does not extend the PagesVersions module in the way that ListerPro extends Lister. Instead, it just provides a web interface for it. I think this is a better long term and more sustainable strategy for handling version support. Core version 3.0.232 also adds version support for nested repeaters and FieldsetPage fields. Support was added in those Fieldtypes directly. Still remaining are PageTable (core) and Table (ProFields), both of which will need their own implementations for versions like Repeater and FieldsetPage needed. But following that, there won't be any unsupported fieldtypes to my knowledge. ProcessWire Weekly published its 500th issue! Congratulations and big thanks to @teppo for his incredible work with ProcessWire Weekly, it is truly outstanding! Thanks for reading and have a great weekend!
  10. @David Karich ProDrafts doesn't have versioning per se, it just maintains a draft version. So the version support will be something different, though the plan is that ProDrafts will be able to eventually use it for maintaining its draft versions. As for how the versioning works, it's very simple in that you have API methods to add, get, save, and delete versions of a page. That's the extent of it. While technically you could code a hook to make it save a new version on every page save, I don't think it would be practical, as a version is an entire copy of a page, including its files. Most likely one would use it to create a version intentionally, and perhaps work on it independently of the live version of the page. Or maybe they would use it to create a restorable snapshot or backup of a page's current state, before making some other changes. I think there are a lot of possibilities for how someone might use it, but for now I'm just focused on its API and making it all work reliably across different fieldtypes. @MrSnoozles A media manager is something I've not needed here, and I get off track and mess things up when I start developing stuff tools I don't have a use for in my own projects. Nearly everything that's in ProcessWire's core is stuff that I develop and maintain because I use it in my client work. When I need to share file or image assets across multiple pages I build a page or group of pages for the purpose, and that is ideal for my projects. A big part of the reason why PW as a framework is so modular and hookable is so that there is always the opportunity extend it in ways that are useful for your own projects. For example, @kongondo built what looks to be a really cool media manager for ProcessWire, though I don't have experience with it beyond reading about it and watching the videos. As for translations of the admin, PW's admin is already 100% translatable, so if you are seeing a mixture of English and another language, then that means that the language pack you have installed is missing translations. But that's something you'd need to ask the author of the language pack about. You can also always submit a pull request to the translation author's language pack, or create your own. PW makes this all very simple. Multisite is another example of a module that I just have not yet had a need surface for in my own work. Though I'm interested in it, so always looking for the opportunity. I'd have to come up with a case where I would use it and find it worthwhile. Otherwise I don't think I could do as a good job of a job as someone that is actively using it. I think the existing multi-site module(s) were built by someone (Soma, Apeisa?) that was using them in their projects. Worth mentioning too that PW will happily serve multi-site already, so long as you add all the hostnames to $config->httpHosts and use conditionals like if($config->httpHost === 'host.domain.com') to decide what content to serve. What I find useful in my work here is multi-instance, being able to boot other sites when and where needed, like we do on this site, where the modules directory actually comes from a separate ProcessWire installation, despite being delivered by the main site.
  11. This week I've continued work on the page versions support that I wrote about last week. While the main PagesVersions module needs more work before it's ready to commit to the dev branch and test externally, it is so far working quite well in internal testing. I mentioned last week how it will support an interface where Fieldtypes can declare that they will handle their own versions. That interface has been pushed to the dev branch as FieldtypeDoesVersions. I've also implemented it with the Repeater Fieldtype, which is visible starting here. Repeaters are so far working really well with versions! As far as core Fieldtypes go, Repeater, PageTable and FieldsetPage are likely the only ones that will need custom implementations. For ProFields, RepeaterMatrix already works with the implementation in the core Repeater (already tested). It's possible that other ProFields will not need custom implementations, though not yet positive. The module that provides version capability is called PagesVersions and the plan so far is to make it a core module that provides API version support for pages. A separate module provides interactive version support in the page editor. I've built this module initially so that I can test versions more easily, but it'll be expanded to provide a lot more. Below is a screenshot if what it looks like in the page editor Settings tab so far: As you can see, you can Edit or Restore any existing version. You can also create a new version from the Live version, or any other version. And of course you can view and delete any versions. When you Restore a version, it essentially replaces the live version with the one that you are restoring. All of this can be done from the module's API as well. Note that the API is provided by a $pagesVersions API variable that is present when PagesVersions module is installed. The API method names and such are a bit verbose right now but may be simplified before it's final. // Get page and add a new version of it $page = $pages->get(1234); $page->title = 'New title'; $version = $pagesVersions->addPageVersion($page); echo $version; // i.e. "2" // Get version 2 of a page $pageV2 = $pagesVersions->getPageVersion($page, 2); // Update a version of a page $pageV2->title = "Updated title"; $pagesVersions->savePageVersion($pageV2); // Restore version to live page $pagesVersions->restorePageVersion($pageV2); // Delete page version $pagesVersions->deletePageVersion($pageV2); Thanks for reading! More next week.
  12. @lpa I think the issue is that your definition is <pw-region> and your insertion is a <div>. But I also think there are very few cases where it's worthwhile to use <region> or <pw-region>, especially when you've already got markup tags present that you can use. Try this instead for your <head> definition: <head id="html-head"> <!-- existing head contents here --> </head> and then use this where you want to append the scripts: <head id="html-head" pw-append> <?=$form->styles . $form->scripts?> </head>
  13. 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!
  14. 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/
  15. @d'Hinnisdaël I tried adding something that would make it ignore a leading "processwire-" on the repo name, so that something like "processwire-ImagePlaceholders" might potentially work, so long as the part after the processwire- prefix is still the correct module/class name. I don't have any repos to test that format with though, so I'm not positive if there might be more to it that I need to account for. Give it a try and please let me know if you find it still doesn't work.
  16. @d'Hinnisdaël I think the issue with the first 2 repos is that the repo name does not match the module name. When you add a module, all it asks for is the GitHub URL. So it loads github.com/daun/processwire-image-placeholders and assumes the "processwire-image-placeholders" is the module or class name. But the module name is actually "ImagePlaceholders". If you change the GitHub repo name/URL so that it matches the module name, i.e. github.com/daun/ImagePlaceholders then it should work. For the TemplateEngineLatte, the module info for that repo lists the version as 1.0.0. So you'd need to update that to 106 or better yet "1.0.6" (string).
  17. @bernhard Since it has a Fieldtype the ability to query it from selectors comes baked in. Though it uses the terms "date from" and "date to" rather than "starts" and "ends". Each are MySQL DATE (not DATETIME) columns, so time isn't a factor. Days and nights will also queryable from selectors. I've not yet added a custom getMatchQuery() method to the Fieldtype, but I think most of the examples you mentioned may even be possible with it using the one inherited from the base Fieldtype class, but I've not tested that far yet. I'm planning to add a custom getMatchQuery() method either way for the days/nights support, so may tweak it further too. @PavelRadvan The disabled days or days of week would be possible. Though if this is for restaurant reservations, I'm not sure that a date range is what you'd need, unless a reservation spans more than one day? Plus, aren't reservations about time as much as date? (There's no time selection in date range). Since it would likely be just one day, I'm thinking the regular/core FieldtypeDatetime/InputfieldDatetime is probably better, plus it also supports time. It uses the jQuery UI datepicker, though I don't think that one supports disabled days. In any case, you could always use a hook or JS to alert the user when they've selected a day that reservations aren't allowed on. If you want to explore it more post in the FormBuilder board and let's see what's possible. @BitPoet I wasn't thrilled with that label either. I converted all (or most) of the JS library's config settings to a PW settings screen and used the descriptions from the JS library in some cases, at least to start. I don't yet fully understand what that option does, so was going to figure it out and then come up with a better label/description.
  18. 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!
  19. This week we'll take a look at a newly released module that enables you to lock page fields or properties from editing on a page-by-page basis. Originally planned as a core feature, I found it worked just as well built as a focused module, so here it is. This post serves as both an introduction to, as well as documentation for this new module— https://processwire.com/blog/posts/page-edit-lock-fields/
  20. This week I've been working on various ProcessWire related projects, but haven't pushed much to the core. There was a core feature I've been working on which I decided to instead put in a module. It's one of those things that should be be really beneficial for some people, but not necessarily needed by everyone, so it makes more sense as a module. This particular module expands upon the page-lock option and permission in ProcessWire. The page-lock option (which you'll see as the "Lock" status in the Settings tab of the page editor) provides the ability to lock a page for edits. This can be really useful if you want to prevent a particular page from being modified for whatever reason. For instance, maybe you are doing a $pages->get('/some/page/'); on the API side and if the path /some/page/ got changed, it would break something in the site. So to prevent clients from breaking the site, you lock the page to prevent them from screwing it up and breaking something on the site. This is quite useful, and often a life saver. But I don't use it as much as I'd like because of one downside. That downside is that it locks the entire page so that nothing on it can be edited. So it's just too heavy of a lock. What if you just wanted to lock the page so that the name, title and parent couldn't be edited, but everything else could be? That's what this new module enables. To lock a field in the page editor, you click its header and hold until a dialog pops up asking if you want to lock it. To unlock, you do the same thing. Once a field is locked, it remains locked (non-editable) until unlocked. Only users with page-lock permission on the page can lock or unlock fields. Locks can also be managed with checkboxes in the page editor Settings tab as well, just in case that is more convenient in some contexts. While these are editor locks rather than API locks, the locks do affect contexts outside the page editor too, such as actions in the page list. For instance, if you locked "parent" then you wouldn't be able to bypass it dragging a page in the Page List. I finished developing the module today, but I've not yet written documentation for it or uploaded to GitHub, etc., so I'm going to give it another day of work and testing before releasing it next week, and will cover more details in next week's post. Thanks and have a great weekend!
  21. This week there are a few updates on the dev branch. Since I'm short on time today, I'll just briefly cover the most interesting ones. Support for OR-groups, sub-selectors, and match same (1) @item groups (see last example at that link) have been added to ProcessWire's in-memory page matching selectors, as used primarily by the $page->matches() method. Previously these features were supported only by the database selectors from $pages->find() and methods that delegated to it. The $page->matches() method that gained these features is used by the core in various places for runtime matching of pages, such as when finding/filtering in a PageArray, for example. Support has also been added for OR-groups to the base Selectors class, which makes it possible to use OR-groups on non-Page objects too. These database-specific selector features were added because there's been a recurring request to support OR groups in places that currently use memory selectors, so this should do that. Though it'll remain just on the dev branch until it's had more thorough testing. While there will always be some differences between database and memory selectors, this does narrow the gap a bit. Thanks for reading and have a great weekend!
  22. This week the ProcessWire core dev branch version has been bumped to 3.0.230. Currently we are about 10 commits ahead of the main/master branch. Relative to that branch, we have 5 issue fixes, 2 pull requests, major improvements to the wireIconMarkup() function and some minor improvements to the ProcessLogger module. We may merge these updates (among others) to the main/master branch as soon as next week. This week I also developed a new security module called LoginTimer that helps to prevent timing attacks in ProcessWire. Admittedly, I started this more for fun than anything, as I don't think timing attacks are a common problem in ProcessWire. But the more I got into it, the more I became aware of the potential dangers of timing attacks (particularly outside of the ProcessWire world). In any case, I now view it as an important security consideration and definitely thought we should have a module for it. Maybe someday we'll have it in the core too. The module is now available in the modules directory and on GitHub, and I wrote up a blog post to accompany the module and that is located here: https://processwire.com/blog/posts/timing-attacks-and-how-to-prevent-them/
  23. There hasn't been a lot of activity on the core this week, as I've been wrapped up in a ProcessWire-based client project (same one as last week). I'd like to put in a few more updates before bumping the version number, which will likely be next week. This week I also released a new module to accommodate a feature that had been requested more than once, but since it's not that commonly needed, I thought it was better to put it in a module rather than the core: Custom Inputfield Attributes for ProcessWire This module enhances both the interactive and API configurability of fields in ProcessWire (both admin and front-end). It can add custom attributes to Inputfields in ProcessWire, FormBuilder, or other Inputfield forms. Custom attributes can be configured interactively in the admin, or they can be added via this module’s API method. Custom attributes can be added to the <input> element of an Inputfield or they can be added to the wrapping .Inputfield element. You can add any attribute that you want (with a few exceptions), whether replacing or appending existing attributes, adding data-* attributes or any other named attribute. This module is available for download now on GitHub with more details on the module info page. Thanks for reading and have a great weekend!
  24. @MarkE The Modules class supports a lot of different options for this, and it figures out which you are using automatically according to how you've defined it. The one that I prefer to use is your second example, that is not static and has the InputfieldWrapper $inputfields as the argument. The static method is the old/original way from when ProcessWire first was released (13 years ago), and it was used primarily so that one could configure a module without booting up an instance of the module. Later on (like ~8 years ago?), the Modules class was upgraded so that it could instantiate the module without initializing it, which made the static option obsolete. The only reason ProcessWire still recognizes it is for backwards compatibility, or if it happens to be preferred by the module developer for one reason or another.
  25. @Jim Bailie Your _init.php is called for every $page->render(); so if you've got more than one page rendering in the request, _init.php will be called for both of them. One example of that would be if your template file does a wire404(); then _init.php would be called for the page that started rendering, and also for the 404 page. The reason for this is that _init.php usually establishes variables and such that you might want to populate or use in your template file or in your _main.php, so it has to be called on every page render. If you have a need for it to only be called once, such as if you are defining functions in it, then just move the contents of your _init.php to another file, like _init-once.php (or whatever you want to name it), and then do this from your _init.php: include_once('./_init-once.php');
×
×
  • Create New...