Leaderboard - ProcessWire Support Forums

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

爱旅游的盒饭 · 下一站是幸福原著小说结局揭秘 ...· 2 月前 ·

体贴的灯泡 · 关于分类数据编码所需了解的所有信息（使用Py ...· 4 月前 ·

善良的花卷 · 评测丰田i-Road电动三轮车怎么样及丰田i ...· 12 月前 ·

还单身的红茶 · 【花蓮市區】懶洋洋Lazy ...· 1 年前 ·

俊逸的茶壶 · EF Linq中的左连接Left ...· 1 年前 ·

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! 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: 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. If you haven't yet noticed it, @teppo has hit the 500th issue of PW Weekly! That is a ridiculously massive milestone and an amazing achievement, and after some quick maths, also tells me that he's held strong for almost 10 years now! I'm not sure what's more surprising, that he's managed to keep it going continuously for this long, or that I remember when he started it... That's a long darn time. I may not be a hugely active member of the community, but I'm darn proud to be a part of it regardless. Thank you so much for your devotion to the PW Weekly project, @teppo!!!! 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! 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 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. if($config->ajax) { // Return search results in JSON format $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find('search_cache%=' . $q);; // Find all pages and save as $results header("Content-type: application/json"); // Set header to JSON echo $results->toJSON(); // Output the results as JSON via the toJSON function return $this->halt();

// look for a GET variable named 'q' and sanitize it $q = $sanitizer->selectorValue($input->get->q); // did $q have anything in it? if($q) { // Find pages that match the selector $matches = $pages->find('search_cache%=' . $q); // did we find any matches? ... if($matches->count) { echo "

We found $matches->count results:

"; echo "

$match->title"; echo "
$match->summary

"; } else { ?>

No results found.

render('elements/_searchbox'); ?> } else { ?>

Search:

render('elements/_searchbox'); ?> Explanation: This part here at the top of the template handles the requests that are send via ajax. This is the important part for later on. if($config->ajax) { // Return search results in JSON format $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find('search_cache%=' . $q);; // Find all pages and save as $results header("Content-type: application/json"); // Set header to JSON echo $results->toJSON(); // Output the results as JSON via the toJSON function return $this->halt(); What this does:

Searchbox

url ?>">

With this simple search form you should now be able to do a basic search that leads you to a search result page. 3. Make the ajax-search „work“ document.addEventListener("DOMContentLoaded", () => { const searchForm = document.querySelector('.searchform'); const searchUrl = searchForm.getAttribute('action'); const searchInput = document.getElementById('searchInput'); const suggestionsDiv = document.getElementById('suggestions'); let selectedSuggestionIndex = -1; // close the auto-complete container when clicked outside the element document.addEventListener('click', function(event) { if (!suggestionsDiv.contains(event.target)) { suggestionsDiv.style.display = 'none'; searchInput.addEventListener('input', () => { const searchText = searchInput.value.toLowerCase(); // Immediately Invoked Function Expression (IIFE) (async () => { try { const response = await fetch(searchUrl+"?q="+searchText, { headers: { 'X-Requested-With': 'XMLHttpRequest' if (response.status === 200) { const data = await response.json(); showResults(data); else { console.log(response.status); console.log(response.statusText); } catch (error) { console.error(error); })(); function showResults(data) { // Show suggestions only if the input has at least two characters if (searchText.length >= 2) { const suggestionHTML = data.map(item => { // Highlight the matching characters using a element with a CSS class const highlightedTitle = item.title.replace( new RegExp(searchText, 'gi'), match => `${match}` return `

${highlightedTitle}

`; }).join(''); // Array to string conversion suggestionsDiv.innerHTML = ''; // Clear the suggestions if input length is less than two characters // create list and append search results const suggestionList = document.createElement("ul"); suggestionList.classList.add('suggestion-list', 'uk-list'); suggestionList.innerHTML = suggestionHTML; suggestionsDiv.appendChild(suggestionList); selectedSuggestionIndex = -1; // show the results suggestionsDiv.style.display = "block"; } else { suggestionsDiv.innerHTML = ''; // Clear the suggestions if input length is less than two characters // Event listener for arrow key presses searchInput.addEventListener("keydown", function (event) { const suggestions = document.querySelectorAll(".suggestion"); if (event.key === "ArrowDown") { event.preventDefault(); selectedSuggestionIndex = Math.min( selectedSuggestionIndex + 1, suggestions.length - 1 } else if (event.key === "ArrowUp") { event.preventDefault(); selectedSuggestionIndex = Math.max(selectedSuggestionIndex - 1, -1); } else if (event.key === "Enter") { event.preventDefault(); if (selectedSuggestionIndex === -1) { searchForm.submit(); else { window.location = suggestions[selectedSuggestionIndex].querySelector('a').href; // Highlight the selected suggestion suggestions.forEach((suggestion, index) => { suggestion.classList.toggle( "selected", index === selectedSuggestionIndex Keep in mind that you need some CSS styes to make it look good and actually work. These are my styles(in LESS format) but feel free to write you own stylesheet for this. search.less: .search-wrapper { position: relative; background: @secondary-blue; color: @primary-blue; .highlight { color: @primary-red; #suggestions { display: none; position: absolute; top: 100%; left: 0; right: 0; z-index: 10; background: @white; .suggestion-list { margin: 0; transition: background-color 150ms ease-in-out; padding: 10px; display: block; text-align: left; &:hover, &:focus, &:active { text-decoration: none; &:hover, &:focus, &:active, &.selected { background: @secondary-blue; li + li { border-top: 1px solid @secondary-blue; That's it! Again feel free to adjust all of the code to your needs. If you have any suggestions how to achieve things a bit easier just let me know. 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/ One of the (few) problems with ProcessWire, in my opinion, is the lack of any native way of handling migrations. Given that PW is such a powerful tool capable of sophisticated and complex web-based applications, this is less than ideal. There is a solution, however, in RockMigrations which accomplishes a lot in a controllable way, provided you are happy to specify your database set-up in code rather than via the UI (albeit that the latest versions allow you to grab much of the required code from the UI). If that suits your need, great. Around the same time as the first versions of RockMigrations, I started developing my own UI-based migrations module, which I have been using with reasonable success for some time. I halted development of the module for a while as RockMigrations developed and I considered switching to that route. However, I decided that my module suited me better and that a real improvement could be made if it was effectively automated so that I no longer needed to specify a migration. So that is exactly what it does: after configuring the module, you add a new migration page with ‘log changes’ enabled (which includes determining what types of objects are relevant for the migration) and work on your development system. Once you have made the desired changes (and tested them!) in the development environment, you go back to the migration page where it has magically captured the objects which have changed and listed them in dependency order. You then ‘export’ the changes, which creates json files to be uploaded to the live environment (via Git or FTP etc.), where they are then ‘installed’ to re-create the changes in the live system. The demo below illustrates this briefly. This first demo shows the creation of a migration. The installation demo will be in the next post, because of size constraints. See post 4 for HD video. Hear, hear! I love the PW Weekly - a highlight of the week! Putting out such a well-written newsletter week after week for 10 years - what an incredible contribution to the community! Hats off to @teppo! I like to read each new issue when it's hot off the press, which is normally on a Sunday (NZ time), but the official email from [email protected] doesn't arrive until the following Saturday. A long while ago I asked Ryan why this is and there was a sensible reason that I've forgotten now, but I can't wait that long for my PW news 🤓. So my solution has been to set up an email alert for the RSS feed using Blogtrottr - that way I can dive into each issue when it's at maximum freshness ✨🎉 Here is one of the latest website we created for a french company renting construction machines and trucks with specialized drivers, based in Le Mans. It’s a rather simple showcase/informational website, but we aimed at making clear (and visually attractive) what is available, what is the skillset and various ways to quickly get in touch. We produced everything, from the design, pictures, illustrations down to the development (ofc). There wasn’t any website before except for social media presence and this task was a follow-up to the update of the visual identity we did. Behind the scene, on the front-end, everything is custom made: we don’t use any frameworks. On the back-end we used the usual suspects and some: I have a json based migrations module that I released some time ago (ProcessDbMigrate). It needed further work, so I have not publicised it further after the initial proof of concept. In the meantime I have improved it enormously and tested it quite extensively with multiple field types including RepeaterMatrix. It is almost ready for re-release. It is a completely different concept to RockMigrations, which is an excellent and well-established module. My module will automatically track database changes as you make them in the back end UI and then export json for installation in the target. It also provides for roll-back, database comparisons and much more. Hopefully out before Christmas. Let me share my story first, you will see why it's important for this discussion. I am a fullstack web developer and I have always found CMSes to be very limiting because usually, their philosophy plays a big part in what you can do and if at all, how it should be done. Most of them even force you into a lot of predefined concepts for the frontend, too. Take WordPress (which to be honest, is not a CMS at all), you start with posts, comments and pages and are stuck with a weird loop concept for the frontend in which posts always get a "special treatment". In 90% of cases if you want to use WordPress as a true CMS, you can only do that by disabling most of the predefined stuff outright and installing a crapton of extensions to just have some custom structures available. With ProcessWire, all of that is different. You start with a clean slate. No predefined content, no structures, no nothing. You can get some niche output with a site profile but changing just anything about the frontend of these site profiles takes you straight into the code. You can't install a plugin to have a fully-fledged shop, add some products and then install a $50 theme, upload the logo and change some colors and call it a day. You have this wonderful API which - as a developer - really is a godsent and allows you to create the most complex structures and have complete control and freedom in the frontend because it literally allows you to do whatever you want. And in the end, we can offer an editing experience to our clients which is a hundred times easier to understand and use than anything done with e.g. WordPress. I think that exactly is what PW's message on the homepage is: It is easy to use for developers while creating the project and easy to use for the clients of the developer when using the finished product. So, to go full circle: I think you are used to systems like WordPress, Squarespace or Wix and expect to have a working website after installing ProcessWire. But this is not the case since ProcessWire is taylored towards web developers. This is also why you need to learn at least a considerable part of the API to then go into the code and create your website, app, own API or whatever your project entails. I don't want do discourage you and seeing new people getting into PW is always a blast. But I fear that without coding, ProcessWire might not be the right choice. It's a shared, easy to use, web-based, non-developer friendly system. Whether I'm a contributor or someone wanting to install a translation for a plugin, I don't need to figure out how author of plugin x wants to handle their translations, and I also don't need to know or figure out how to create a GitHub account, open pull requests, etc. This point alone is a major benefit and lowers the bar for contributing 🙂 Just for the record, many plugins still bundle translations with the source code. So yes, both systems can co-exist. Anyone can contribute without core/theme/plugin author(s) having to do anything. I for one have access to Finnish translations for a few plugins. Permissions are handed down by general translation editors for the locale, which is much easier than having to contact individual plugin authors who may or may not be around and active, and may or may not be interested in bundling some language they have no personal interest in. Once a locale has enough coverage, it automatically becomes installable via the admin and via WP-CLI. Personally I use WP-CLI for managing site translations, as it makes things a lot easier to automate. Installing and updating translations is literally one command away, which — as someone who manages quite a few sites — is a big bonus. This, of course, only works for plugins that have been translated this way. Not all have. It's not a perfect world. Finally, the system handles versions properly. For an example if I wanted to submit a correction for the Finnish translations for ProcessWire version 3.0.184, there's no easy way to do that. Maintainer of the Finnish translations repository could set up separate branches or some other way to handle it, but this would be a case by case thing, and there's no guarantee that the language pack maintainer is interested in such a thing. Anyway, I'm still interested in this idea, but have not had time to pursue it myself. Maybe one day, unless someone else solves it properly before me 😉 In my opinion it is a viable idea, but there are many questions to answer, and quite a few of those are not straightforward. Also I believe that in order to gain traction this would need to be somehow integrated into our current translation tool(s) and it shouldn't be too opinionated (for an example I personally would prefer it to not update anything completely automatically, as was suggested here earlier.) Well, since @monollonom tagged me I thought I'd tinker. I added a one-click button to Fluency that translates any module file, core or otherwise, in seconds. It's integrated with the native ProcessWire language translator pages. Some details here. It makes it entirely possible for everything a user interacts with in the admin to be translated within minutes, not hours. Language is a tough nut to crack and applying a universal solutions are difficult. It's huge task for a module developer, contributor, or a core maintainer like Ryan, to take on when they are providing free and open source software for the community. The fact that ProcessWire handles language so well to begin with shows a thoughtful approach by Ryan and ProcessWire contributors, especially if it is as rarely as you assume. Try Fluency and let me know if it helps out. I'm a WordPress guy with 10+ years experience. I'm well aware of the shortcomings of WP (chaos API, no built-in multilingual support, to name a few), but was always able to find a way to work around these. In 2023, due to the never-ending praise from some of my developer peers, I finally gave ProcessWire (and also Kirby CMS) a try for two small projects. If nothing else, these excursions gave me a more senior perspective on the advantages and shortcomings of these three content management systems (none of them is perfect). I was impressed by many thoughtful decisions in ProcessWire's setup, data structure and API. But I am missing one last thing that both WordPress and Kirby have solved in a very clean an comfortable way: A clean solution for deploying fields between environments and committing them to version control. ✅ In Kirby, all fields and templates are being defined using YAML blueprints, so they are also easy to deploy and version control (although YAML configs come with their own set of shortcomings 😄) ❌ In ProcessWire, I couldn't work out a reliable way to define (/autosave/sync) the fields in my code base. 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. 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. 🤞 Sometimes, you want to search a text field by the length of its content. FieldtypeText doesn't provide this functionality (yet). It's possible to add the necessary SQL to a query by hooking into PageFinder::getQuery like @bernhard pointed out here, but that's of course not really straight forward. There's also an open feature request for FieldtypeText in processwire-requests. FieldtypeTextWithLength is an extension of FieldtypeText, so you can switch your field's type between the two without loosing any information. After switching your field to "Text with .length Selector", you can search by the (character, not bytes!) length of the content: $pagesWithShortHeadlines = $pages->find('headline.length<10'); You will also find a new "Length" subfield when using Pages -> Find in the PW backend: 1/ I installed Softaculous for the first time, and the installer doesn't offer to integrate a site profile as with the latest version, which I downloaded and installed manually. It was by studying the documentation that I learned about the existence of profiles (and many other things) and the installation procedure and, if I hadn't spent time reading the tutorials, I'd never have understood the concept of profiles and templates which, incidentally, I still don't fully understand, but I'm working on it ;) All this to say that the beginner who installs with Softaculous has every chance of getting lost if he doesn't have the patience and motivation to read the docs first, which we never do when we test unknown CMSes in general. :-D By installing ProcessWire manually via FTP, it's already much better. Which brings me to point 2/ In the presentation of this CMS, it's repeated very often (too often) that it's simple, easy, within everyone's reach and, while it's true that someone with a bit of experience can manage it because the documentation and help systems are very well done, the lambda user who's used to CMS but isn't a developer will fear his own limitations. I myself am impressed by the quality and possibilities offered, but I feel very small when I read the various topics on these forums. How far would I go?) Having said that, I think this is a wonderful product and thank you all warmly for having invented it and maintaining it for everyone's happiness. :) @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. So your $page should better be an OrderPage (custom page class) and that pageclass should have this method: public function setOrderStatus($status) { $this->setAndSave( 'order_status', $this->wire->pages->get("/path/to/order-statuses/$status") I know the benefit looks little, but the code does not only get cleaner to read: $page->setAndSave('order_status', $pages->get('/path/to/order-statuses/pending/')); // vs $order->setOrderStatus('pending'); It gets also more error-proof (what if someone/something created another page with name "pending" somewhere else in the tree? And not to forget your system will be better and easier to maintain. Imagine for example you change the path of your statuses one day. You only change the path in setOrderStatus() and you are done, rather than finding all instances of ->setAndSave(...). Also maybe one day the client want's E-Mail notifications on changed statuses... Simply go to setOrderStatus() method and add the mail code there. If you have several ->setAndSave('order_status', 'something') sprinkled around you might be tempted to add the mail sending on several locations or you might forget it somewhere and you'll have introduced an unnecessary bug 🙂 PS: I'd even more prefer setStatus() but that's already taken by the Page baseclass. updateStatus() would also be an option. But setOrderStatus() might be the clearest anyhow 🙂 I have created 4 larger wesites with drupal 7 before I got to know processwire. The modules and the community are great with drupal. But in the end I found it extremely annoying and frustrating. It was no fun and the projects often ended up taking much longer than expected. I can't say how it is with the newer versions ... If you want to have clean code the templating is quite complex. It seemed to me that the Drupal way was rather to take the very complex code as it is output (with nested elements and classes) and then just customize or hide elements in CSS. The module "views" (perhaps the most popular in drupal) is quite complicated and in the end limited in its possibilities. What is complicated to click together in "views" can often be done in processwire with pages->find in one line! What I also found annoying was that, depending on the modules used, the backend no longer looked very uniform. This is much better in processwire. If I have to make adjustments to the websites today, it takes me a while to think my way back into the structure and understand which module creates which content in which place. I am really happy to have found processwire and will certainly not be using drupal for another website. In my ready.php file have this global variable that acts as a page reference to the settings page: // Global Settings Page as API variable $wire->wire('globalSettings', $pages->get('template=global-settings')); Then on any template file I can access a field on that global settings page like this: body; ?> I know it is simple, but the reality is that in client projects it often still ends up being a mix of and English, because not all modules provide translations (the community seldom submits pull requests for languages) and there is no time to translate everything. I think that ProcessWire is lacking in this area has to do with you rarely needing it in another language but English. My idea how this could be improved would involve three relative simple steps: 1. Set up a community translation tool, like Weblate (https://weblate.org/), where people that want to contribute can easily see which translations are still missing. Weblate is really good feature-wise, but the interface for adding translations could be simpler, so another tool might fit better. 2. Write a crawler that goes through all the uploaded modules and core files, extract the translatable phrases and upload those packages to Weblate 3. Write a ProcessWire module that maps the languages defined in ProcessWire with country codes, then automatically downloads the matching translation files from Weblate whenever a module is added or updated That's not how RockMigrations works. At least not at the moment. And that has several good reasons. I'm not saying that such an approach is bad. But it is very complicated to implement, it comes with a lot of (maybe unsolvable) problems and even if everything worked it has a lot of limitations by design. I didn't want that for RockMigrations, so I built it differently. Quite correct, except "even if everything worked it has a lot of limitations by design". I'm not sure what those might be. ProcessDbMigrate is working pretty well now and I will let people know when I am happy with the testing (and documentation!). Yes, it was very complicated to implement but it is now coming together nicely. I think RockMigrations is great for people who want to work that way, but I chose a different path and will happily accept criticism (and, even better, constructive suggestions) if it doesn't work as intended. ProcessDbMigrate uses multiple migrations and you can define one to export the database to another project. I am using it to install another module in new projects and plan to use it to create a template project from a live one. I'll admit that it is early days yet and that it is probably not as flexible as RockMigrations, but I'm not convinced it is a 'huge drawback'. ProcessDbMigrate uses names and paths not ids. If a name is changed it tracks that, so that it updates the target correctly. So ids do not need to be the same. You cannot change fields etc. in the target if they are the subject of a live migration (unless you disable that feature), but you can after it has been fully installed and 'locked'. Of course if someone updates the live then someone else creates a new migration from an old database version that over-writes it, that is a problem! So far I have not had a problem with any type of change that you can make in the UI (including parent id and template id references - these are converted to names and then converted back on installation) 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. Fair point. Particularly re any special field types introduced in modules. ProcessDbMigrate does cater for most of them (I am just updating it for FieldtypePageTable) including some which store attributes as objects, but would need updating if there are major changes or additions to the core (my guess, though, is that these are very unlikely to be breaking changes). It is clear to me from previous discusssions that @ryanis not convinced of the need for this in the core and, indeed, does not feel the need for it personally. I consider that a shame as the lack of this functionality is in my view the only major missing feature in ProcessWire. The topic has been debated here numerous times with no clear conclusion. As a consequence, those of us who feel the need have had to turn to modules - either our own or others'. RockMigrations has been released for a while and is well-supported. Both that and ProcessDbMigrate are open-source so, unless @ryanchanges his mind, it will be up to the community to contribute to module development or, indeed, take it over should the original author no longer maintain it. That will depend on how important the community thinks it is. But I realized you can simply do this in ProcessWire making it much easier on the eyes, with the added benefit of not having to update the code if the path to the page changes: $page->setAndSave('order_status', 'pending'); My mind is blown. It makes me wonder what other little things I haven't realized yet. Install options There are two ways to install PAGEGRID: Installing just the module or installing the theme. The theme is more opinionated and comes with pre installed modules to handle SEO, generate a sitemap, or display a cookie banner. If you prefer to have less dependencies, we recommend you only install the module. It’s everything you need to run PAGEGRID and verion 2.0. made it much easier to install. How to install and setup the module @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 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? Open in panel Site.module.php is a concept that I'm using for several years now and it is great. It's an autoload module that holds all the project specific stuff that belongs nowhere else. Similar to _functions.php but with all the benefits of OOP. Years ago I've created modules named after the project, like for the Foo project it was Foo.module.php and for the Bar project it was Bar.module.php; But I much more prefer Site.module.php which is why RockMigrations offers you to create this module for you (if you want). Nowadays whenever I'm working on any of my projects I instantly now where to look for: Site.module.php - that saves brain power for more important tasks 🙂 I've done a video about hooks and custom page classes and the same concept applies to migrations (the video starts at the interesting part): RockMigrations has been a big time saver and working reliably for me for the past 2 years or so. I haven't tried other solutions mentioned here since they are not actively maintained. As for having this functionality in the core. Yes, that would be great, indeed. Honestly, I don't understand, why @ryan hasn't implemented it yet. Maybe also because there is a great solution with a well designed API available already as a free module? Still, I think it would benefit the project if this was either in core or available as an optional core module. IMO, migrations are essential, especially when using PW for bigger projects and when working on projects in a team. As for the discussion here about potential problems with migrations brought up by @MarkE , I was able to work around all of those with RockMigrations since it is also declarative, but not destructive (unless explicitly intended). The "few things too many" argument is flawed since all the extra functionality is optional and therefore doesn't impact performance. And the addon-features are well designed and can be very useful. Performance with RockMigrations is really good. Only very large migrations take some time. I have a project with about 4000 lines of migrations for templates, fields, pages and roles in my main migration file and then some additional 1000 lines spread throughout modules and these take about 20 seconds. Since you are not doing migrations all too often, this is very tolerable. Migrations on smaller projects are almost not noticable. To create a new field, you need to select a Fieldtype, not an Inputfield. Fieldtypes often have a matching Inputfield, but some support different Inputfields to faciliate the input. The Fieldtype is the part that takes care of storing and loading the data for the field, while the Inputfield provides the UI for entering that data. In the case of InputfieldTextTags, it doesn't have a matching FieldtypeTextTags, but rather complements the existing Fieldtypes FieldtypeText, FieldtypePage and FieldtypeOptions. So you need to create one of those and then, when you configure the field, choose "Text Tags" as the Inputfield of choice. Once you save it, you will see the configuration options specific to InputfieldTextTags. While ProcessWire doesn't have built-in support for migrations or version-controlled field definitions, it already supports export and import of field definitions via JSON, albeit only manually via the admin interface. However, it being JSON-based should be a good enough base to start automating some of this, e.g. by saving and reading the JSON from disk. That would also make them version-controlled as well. I agree this should be part of the core. Most CMS have solutions for this and it'd be a useful feature to advertise. The landscape of modules here is somewhat splintered. The module that integrates best with the core, Migrations, has unfortunately been deprecated. I haven't fully tested RockMigrations yet, but from what I've seen it seems to be doing a few things too many (snippets, "magic pages", "files on demand") and I'd prefer a module that limits itself to migrations, if not just for performance. +1 for a ProMigrations module from @ryan to ensure the best level of integration into the core.