Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 12/28/2021 in all areas

  1. Happy New Year! Hope that you all have a great end to 2021 and start of 2022. No major core updates to report this week, just a few minor issue fixing commits, so no version bump today. The dev branch is getting close to 100 commits (and at 7 versions) above the master branch, and with even more improvements/fixes/optimizations than that. So we may try to get a new master/main version out in early 2022, as I'd really like to get more master versions out in 2022 than we did in 2021. Some portion of our audience does not use the dev branch where most of the activity happens, and so it might be nice to share more of that activity on the master/main branch. That's one of many things I'm thinking about as the New Year approaches and am certain 2022 is going to be a great year for ProcessWire and the community. Hope that you have a great weekend and Happy New Year!
    38 points
  2. This week we have ProcessWire 3.0.192 on the dev branch. This is about 20 commits ahead of the previous version and contains 11 issue fixes and 5 pull requests, along with various other updates. PR code contributors in this version including Daun, MrSnoozles, Radon8472, BernhardBaumrock and Tyde. Thanks! For more details see the dev branch commit log. In addition to core updates, in recent weeks I've also been working on a new module similar to the PageAutosave (developed for the admin) except that it is for front-end forms. It works with any front-end form (whether home brewed or from something like FormBuilder) and remembers the entered form values every time a field is changed. If the user doesn't submit the form, they get an email with a link to finish filling out the form after a configurable period of time. This is especially nice for order and reservation forms. Accompanying the module is a separate Process module that lets you view all the forms in progress in the admin. Each form entry has its own unique URL, making them easy for users to return to, from any device. Once the user submits the form, the data gets removed from the pending submissions database. This is something I've been meaning to develop for awhile, and with the admin PageAutosave module still fresh on my mind, I thought now was a good time to do it. Thanks for reading, Happy New Year and have a great weekend!
    25 points
  3. 18 points
  4. This week we have some improvements to the $pages->findRaw() method. Most of these are based on requested improvements in either GitHub (like #427) or the forums: Support for selecting parent properties/fields in the return value, i.e. $pages->findRaw("selector", "parent.title"); // Example 1 $pages->findRaw("selector", [ 'title', 'parent.title', 'parent.parent.title' ]); // Example 2 Support for selecting page 'meta' data in the return value, i.e. $pages->findRaw("selector", "meta"); // example 1 $pages->findRaw("selector", [ "meta.foo", "meta.bar" ]); // example 2 Support for selecting "references" in the return value. References are other pages that reference the found page(s) via Page reference fields, just like the $page->references() method. $pages->findRaw("selector", "references"); // example 1 $pages->findRaw("selector", [ 'references.title', 'references.url' ]); // example 2 If you want the references to be indexed by field name, just include "references.field" in the requested fields: $pages->findRaw("selector", [ 'references.field', 'references.title', 'references.url' ]); Support for selecting title and/or value from options (FieldtypeOptions) fields, i.e. $pages->findRaw("selector", [ 'my_options_field.*' ]); // example 1 $pages->findRaw("selector", [ 'my_options_field.title', 'my_options_field.value' ]); // example 2 Support for a new "flat" option that flattens multidimensional arrays in return value. This is best explained by an example. Let's say we did this: $pages->findRaw("categories.count>0, limit=1", "title, categories.title" ); And it returns an array similar to this for every matching page: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories' => [ 1035 => [ 'title' => 'Security' ], 1288 => [ 'title' => 'Users' ] ] ] Now let's try the flat option: $pages->findRaw("categories.count>0, limit=1", "title, categories.title", [ 'flat' => true ]); (side note: you might already know this, but fields and options can also be bundled in the selector like this below, which is identical to the above): $pages->findRaw("categories.count>0, fields=title|categories.title, flat=1"); It flattens any multi-dimensional arrays in the return value to be indexed in the same way that you requested them in the $fields argument: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories.title' => [ 1035 => 'Security', 1288 => 'Users' ] ] In addition to these updates for the $pages->findRaw() method, this week there have also been updates to the $sanitizer->float() method and InputfieldFloat module. Now both support numbers with E notation such as 1E-2, 10E-14, -1.253E-5, etc. There are also some new values for the getString option on the float sanitizer. I don't work with this kind of stuff very often, so thanks to @MetaTunes on GitHub for helping to figure it out. Lastly, the ProcessTemplate module also went through a refactoring with some minor improvements this week. Thanks for reading, have a great weekend!
    17 points
  5. Demo site (frontend) is here. I'll do a write-up about it soon. The cart is htmx, Tailwind and alpine.js powered. Borrowed bits of templates here and there, threw in some Tailwind CSS components and this is what we get. Oh, yes, all the blemishes are mine. Site is not optimised but it is fast enough. It should give better feedback after item is added to cart. Will work on it later. Full checkout works. The PayPal widget will not charge you though. It will just crash (with a lot of grumbling in the console). Over the weekend I'll set up a GitHub repo with this demo as a starter site for our testers (especially). I also plan to wrap up the docs and prepare access for testers ready to download by Monday. I'll send you (testers) an email in this respect. After (or even before) that I'll write up a bit about what to expect in this first release and what not to expect. Happy new year.
    16 points
  6. ProcessWire 3.0.193 resolves 6 issues, makes improvements to the template and module editors, adds new hooks, adds improvements the $pages->find() findRaw method, and more. We covered some of these updates in last week's post, so we'll focus on what's new this week. First off we have a new advanced mode feature that lets you edit the raw configuration data for a module. This can be useful for various reasons, especially for module developers. If you have $config->advanced = true; in your /site/config.php file, you'll see a new option on your module information screen that enables you to directly edit the raw JSON configuration data for the module. There's also an option that lets you view the raw JSON module information data. Unlike the configuration data, this isn't editable. That's because it comes from the module directly (overtime you do a Modules > Refresh) or is generated at runtime, so there's little point in editing it here. In my case, I've found these new tools helpful for clearing out old and/or irrelevant configuration data during module development. In some cases, having the ability to edit this data may help to identify or fix issues that previously would have been difficult to do without using the API. If there's interest, I may move this into a dedicated (non-core) module that also lets you directly edit field and template configuration data too. But for now the feature is in the core, but just requires advanced mode before it appears. A few new hooks were added this week: Fieldgroups::fieldRemoved($fieldgroup, $field) Called after a field has been removed from a fieldgroup/template. Fieldgroups::fieldAdded($fieldgroup, $field) Called after a new field has been added to a fieldgroup/template. Fieldgroups::renameReady($template, $oldName, $newName) Called before a fieldgroup is about to be renamed. Fieldgroups::renamed($template, $oldName, $newName) Called after a fieldgroup has been renamed. Templates::renameReady($template, $oldName, $newName) Called before a template is about to be renamed. Templates::renamed($template, $oldName, $newName) Called after a template has been renamed. Fields::renameReady($field, $oldName, $newName) Called before a field is about to be renamed. Fields::renamed($field, $oldName, $newName) Called after a field has been renamed. These accompany the existing addReady(), added(), deleteReady(), deleted(), cloneReady(), cloned(), saveReady() and saved() hooks available for fields, templates and fieldgroups. Last week a couple people asked about versioning and migration of stuff in PW (like fields, templates, modules, etc.) and if there were any plans to provide additional tools for that. For the projects I work on at least, this part of the development process consumes so little time that it doesn't warrant developing more stuff for it. But I understand others might find it useful, so for those that would, I'd rather keep the core lean and instead leave that to tools/modules built by experts like Bernhard and others around here. I think it's important that whoever develops and maintains such features also be the same one(s) that would use them. But if any kind of core updates would be helpful to developers looking to implement more features here, I'm on board. Whether that means adding more hooks to specific events (see above as examples), maintaining field/template/module data in files in addition to the current DB tables, or anything else that helps such modules, this is all possible and likely simple for us to support in the core. So just let me know what I can do to help. While not full-featured migration tools, we do have useful field, template and page export/import tools in the core already, and those will of course continue to be maintained and improved, and may be expanded to include modules too. Thanks for reading and have a great weekend!
    14 points
  7. Well hello, today is the day I would like to introduce Flowti, my biggest Project I have worked on for the last 2 1/2 Years and the reason I am developing Symprowire, too. So, what is it all about you may ask. Flowti is my daily driver to Plan, Document and Execute Projects Flowti is my tool to work on concepts and ideas Flowti is my tool to present Work Flowti is my tool to organize and support Product Management Work Flowti is my digitalization Framework To give you a glimpse about what Flowti is already capable of I attached some screenshots for you to study 😛 To make this one short, I plan to fully Open Source Flowti this year after Symprowire reaches v1.0 and will use this post as a way to show progress. Cheers, Luis
    12 points
  8. The problem: Synchronizing fields and/or templates made on the dev server with the live server is cumbersome. At the same time, there is no version control of fields and templates, which some folks (including myself) see as a disadvantage of ProcessWire. A way to have version control to track changes and replicate automatically would be desirable. There is the template and fields export feature in ProcessWire which has said for ages that this is only a beta version, although I have used it many times without any problems. However, even with this method, it is very cumbersome to reconcile changes between dev and live. You have to remember which fields / templates you created and select them, then copy and paste them on the dev server. This is a manual, cumbersome and time consuming process. Existing solutions: For this reason, several solutions have been developed such as: Migrations by @LostKobrakai https://processwire.com/talk/topic/14603-rocksvn-brings-version-control-to-your-fields-templates/ ProcessWires Template's and field's export function https://processwire.com/modules/rock-migrations/ https://processwire.com/talk/topic/25307-oh-no-not-another-migration-module/ https://processwire.com/modules/auto-export-templates-and-fields/ Other systems like Laravel, Craft, Kirby and Statamic use configuration files (migrations, YAML) to manage fields / templates, which allow to create a state of fields / templates. Since the configuration is done in a file, you can of course manage it with git (or other vcs). By configuring in a file, it is also possible to automatically execute these migrations during a git push through different deploy pipelines like github actions, buddy, bitbucket pipelines and thus you have the desired state on the desired server. Where to go from here? In another post @bernhard showcased a prototype, that uses a YAML-file to create and manage fields / templates in ProcessWire. At the same time he showcased a YAML recorder which writes all changes that are made to templates and fields into a YAML file, which looks very promising: I think a combination of a recorder and a YAML config file would be a optimal solution, at least for me. What format to use for such a configuration file was and has also to be discussed:
    11 points
  9. Lister Native Date Format Allows the date format for "created", "modified" and "published" columns to be set within a Lister or Lister Pro instance. Why? Lister formats the "created", "modified" and "published" columns as relative time strings and doesn't provide an easy way to change this without writing code. Sometimes a value like "3 weeks ago" is not precise enough and you want to see an exact date/time in these columns, perhaps only temporarily before switching back to a relative date. Details An icon is added near the top right of the Lister that reveals a dropdown where you can select from a list date formats that you define in the module config. The Lister will remember your chosen date format the next time you visit the Lister. If you have Lister Pro installed then each Lister Pro instance will remember the date format previously set for that instance. Configuration In the "Date options" field in the module config, enter a list of date formats that are compatible with wireDate(), one format per line. The default date format used by Lister is "rel". You can also set a default date format for native fields which will apply to all Listers that haven't yet had a date format chosen from the dropdown. https://github.com/Toutouwai/ListerNativeDateFormat https://processwire.com/modules/lister-native-date-format/
    9 points
  10. Please do, I'd be very interested to read that! It seems like this should be doable via a module in PW. I have a work-in-progress module that does something like this. It's not complete and haven't looked at it a while but it seemed like a promising avenue at the time. I think if the concept could be illustrated in a module then Ryan might see the benefits and then hopefully incorporate the features into the core. Seeing as you've clearly spent some time thinking about these issues, would you mind writing up a wishlist of what things you think PW should handle via files for the sake of version control? Fields and templates are the obvious things but you also mentioned translations which I wouldn't have thought of (I only work on single language websites) so it would be great to have a comprehensive list of problem areas for version control. Thanks in advance! 🙂
    9 points
  11. I use the tools that ProcessWire comes with. I spent a lot of time making them simple and easy to use, and that's what I like to use. Just as an example, let's say that I've got a website and a client wants to add a full featured blog to it. I'll develop it on my local copy of the site and it might involve creating several fields, templates and template files. I'll take a day or two to develop it and when it comes time to migrate the finished work to the live server, that's the fun part, but there's not much to it: Create or export/import the new fields on the live site first, then do the same for the new templates. Copy the new or updated template files (and related CSS/JS assets) into place. Create or export/import the pages needed by the blog, and it's done. A blog is just an example but it's the same as any other update. It's a painless process that always goes quickly and smoothly. This part of it takes maybe 5 to 10 minutes and is one of my favorite parts of the project, like driving a new car and then seeing it for the first time in your driveway. I like to oversee this part of any project and have no need to optimize it further so guess I'm not the target market for add on migration tools. That's correct, it would be fairly straightforward.
    8 points
  12. @bernhard YAML is preferable because it's declarative instead of imperative. This has a couple of side-benefits, like cleaner diff views in git, no formatting issues or different styles and no 'noise' in your commits (all only relevant if you have a git-based workflow with pull requests). But the big thing is that it makes it impossible to create environment-specific configuration, which is exactly what you don't want. If you embrace that the configuration is the source of truth for the entire site state (excluding content), you won't need this anyway. Take your example where you switch a field based on whether the languages module is installed - I would flag this in a PR and consider it an antipattern. Whether a site is multi-language or not should be part of the configuration. If it isn't there's no way to guarantee that the code which works in staging will also work in production, so at that point you're doing all the work for controlled deployments and version control but not getting the benefits. Another downside of PHP is that it's onedirectional by default. With YAML, if a deployment fails, you can just roll back to the earlier version and apply the configuration of that version. With PHP, this may work if the PHP migration is just one single $rm->migrate call with an array of configuration (so basically it is a declarative config). But you have no guarantees that it will, and if you have any logic in your migration that depends on the previous state of the site to migrate to a new state, this migration is irreversible. Migrations do have their place - if you really need to perform some logic, like moving content from one field or format to another. But besides that, declarative configuration files are preferable.
    8 points
  13. Would you mind telling us a bit more about your workflow in regards to projects and their migration? This would be super interesting.
    8 points
  14. This would be some kind of a dream for me to have in ProcessWire. 🤷‍♂️
    8 points
  15. Developing on Linux (currently Arch/KDE Plasma) for the last 16 years. Would never go back to proprietary alternatives. Why pay for something that should really be free for all? Devtools: Editor: VSCodium with PHP Intelephense, GitLense, PHP Debug (xdebug support), Prettier (Code Formatter), Todo Tree and @bernhards PWSnippets. Local dev env: after having used vagrant for a long time, about 4 years ago I switched to https://laradock.io/ for local docker environment. Ensures portable environments across multiple machines PW modules used on almost every project: TracyDebugger, WireMailSmtp, ProFields (mainly for Repeater Matrix), TablePro Asset building pipeline: npm scripts / gulp / webpack. Will have a look into Laravel Mix. Might save time although I actually like to fiddle with all the configs. Deployment: for older and ongoing projects mostly SFTP. For new projects git with git hooks. This is so much cleaner. Not using any service but creating own git hooks on the server. git must be available on the production server. Staging servers used rarely. Mostly deploy from local to production. Hosting: I do not offer hosting services. This is up to the client. Personally I use https://uberspace.de/en/ which is a command line configured shared hosting provider from DE with a pay what you want pricing model
    8 points
  16. Hi @Malinda. Welcome to the forums and ProcessWire. We have a jobs board here, in case you need it in future: https://processwire.com/talk/forum/22-jobs/ Yes. That is to be expected. For YouTube, you have three options at least: 1. Tell CKEditor to stop stripping your iframe, as explained here: 2. Use Hanna Code. An example can be found here: There are simple Hanna Code examples but I cannot find them at the moment. 3. Use one of the available Video embed modules: https://processwire.com/search/?q=video&t=Modules You would need to be a superuser (the higher up level [highest in fact]) to be able to access ProcessWire templates. However, the files that go with the templates (template files) and styles are stored in your directory/folders where your ProcessWire installation files are stored (on your webhost / server). Access to them is usually via FTP or a CPanel-like dashboard. The template files will be under /site/templates/. The location of styles is a matter of choice for your developer but the usual locations are /site/templates/styles/ or /site/templates/css/ or similar. By head area I assume you mean the <head></head> of a template file or an auto-appended file like _main.php (/site/templates/_main.php). The JavaScript would be picked up, yes. However, the code does not (shouldn't even, I would argue) go into CKEditor. It would be stripped out anyway by CKEditor. I am not sure what you mean by code in this case as well. Usually, that code would go into your /site/templates/scripts/main.js or /site/templates/js/main.js. The main.js is usually a custom file created/amended by your developer so it could be named something else, even scripts.js. I hope this helps. It would be helpful to know the what version of ProcessWire you are using. All the best 🙂.
    7 points
  17. Sorry I missed your second post... Actually something similar would already be possible using RockMigrations. At least for basic setups. I'm not sure how that can work for more complex setups though. I'll try to explain that by an example: Let's say we created a new blog module. We need a blog page (parent) and several blog-items (children): - home '- blog |- blog entry 1 |- blog entry 2 ... This setup could easily be built into a module using rockmigrations: <?php namespace ProcessWire; class MyBlog extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyBlog', 'version' => '0.0.1', 'summary' => 'blog module using rockmgirations', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->fireOnRefresh($this, "migrate"); } public function migrate() { $this->rm()->migrate([ 'fiels' => [...], 'templates' => [ 'blog_parent' => [...], 'blog_item' => [...], ], ]); $this->rm()->setParentChild('blog_parent', 'blog_item'); // --> this sets the family settings for both the parent and the child template - how long does that take by hand? ;) It means that all pages having the "blog_parent" template will create a "blog_item" page automatically when you click on "add new page". Basically the stuff that you set on the family tab of the template. } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means I'm literally defining my config in the module code. We could also have the config read from a config.yaml - that would really be the same (just less powerful IMHO)! The problem arises when you want to make that config customizable. For example you want a page reference field to select the author for every blog post. Building that into the blog module would probably not be a good idea because not every site might need such a field. What I do in such situations is this: I make the migrate() method hookable and create one module that handles all the project-specific stuff: <?php namespace ProcessWire; class MyProject extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyProject', 'version' => '0.0.1', 'summary' => 'module that handles site specific stuff', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->addHookAfter("MyBlog::migrate", $this, "migrate"); } public function migrate(HookEvent $event) { $this->rm()->createField("author", "page", [ 'label' => 'Select the author', ... ]); $this->rm()->addFieldToTemplate("author", "blog_item", "title"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } That means you can have your blog module that you can reuse from project to project (and improve it and just pull changes if you need to) and you can still customize it the ProcessWire way (which we all love I guess). BUT Now we got a new field on the "blog_item", the "author" field. So the config.yaml of the blog module would change, wouldn't it? I'm not sure how CraftCMS handles such situations? And that's one of the reasons why I think that efforts like this are going in a wrong direction. It sounds intriguing for sure to have something like a "migrations recorder". I'm working or at least thinking about that since 2016. But I simply can't imagine a way that could reliably work in all situations. RockMigrations does. And it does it really well. And it does it for almost 3 years now and has evolved a lot. It's still not perfect for sure. But I don't think that This feels wrong. I'dont know how to explain. I think you have a good understanding of composer and such things. Likely a much better understanding than I have. So if it is true what you are saying, I must be doing a lot wrong in my daily work or at least I must be understanding a lot wrong... Because a lot of my workflows do feel very version control friendly. And I've lately started working in a company in vienna where we work on ProcessWire projects with fully automated workflows. We work in a team. We work on different local machines. We deploy to staging and if everything works (which has been the case 100% so far), we deploy to production with a single click. But maybe I'll change my opinion some day and look back and laugh. Maybe I should just try CraftCMS. Maybe many other fancy new tools. At my company they also work (or worked) with NEOS. They said they liked to be able to define fields and templates in code. They said that was one of the (few) things they didn't like about ProcessWire, because they love professional workflows and automated deployments... But they also admitted, that it was somewhat painful to define fields and templates (I don't even know how they call it in NEOS, so please excuse me if I'm talking nonsense). They said you have to add pieces of config in that file, then change another piece in another file. And end up changing many files for simple changes. Now they like RockMigrations 😄 And such comments make me think I am on a right track and we as ProcessWire enthusiasts are not that far away from what you seem to be missing. @MoritzLost have you ever heard someone saying "ProcessWire is great for small websites, but not for larger, more complex ones"? We all know how wrong that is, don't we? That's the way I feel when people here on the forum are talking about missing migration / version control features... PS: I tried to keep this post short and not so emotional. I think I failed, sorry 😄
    7 points
  18. @adrian Last year we've started using Craft CMS for some new projects, which has full support for version control out of the box. In terms of feature set it's quite similar to ProcessWire – you can define your own fields and entry types (similar to ProcessWire templates) and create custom field layouts. It's not a flat-file system, it does use a database. It also provides an API similar to ProcessWire's $pages to query for entries (pages) or other data. To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily. You can even read a pull request in Github and see what changes it introduces to field/entry type settings, it's great. It's called project config, here's the documentation. Particularly pleasant is that you can still use the backend to create fields and field layouts – every change in the backend is automatically written to the config folder. So you can just create field layouts in the backend and everything you need to track it in git is already there when you're done. To propagate changes between environments, the CLI has commands to apply the project config to the current environment (database). I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set, support for version control and development experiences. There are some good ideas there that ProcessWire could really benefit from. BTW, if you want to track content in git as well as configuration – we also looked at Statamic, which does support flat files and can commit every backend edit to git. Haven't tried it though. @szabesz Not sure if it's that easy, making every aspect of ProcessWire version control friendly would require massive reworks. Including making ProcessWire and it's module installable through Composer and reworking the directory structure to have a better distinction between content and config, as well as dependencies and custom code. This would need to be ProcessWire 4 (at least). Not sure this can be done if ryan isn't looking to put massive amounts of work into this. I don't have the impression that this is the direction ProcessWire is going – though I'm happy to be proven wrong.
    7 points
  19. This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!
    7 points
  20. Hello Padloper Alpha/Early Beta Testers. Shortly after this post, you will receive an email inviting you to access and test Padloper 2. Thanks! If you don’t receive an email within 2 hours, please let me know. A few things to note before you dive in. What to Expect Padloper 2 is a native ProcessWire module. It is not an SPA. A previous iteration powered by VueJS was discontinued. Instead, there is some sprinkling of htmx, alpine.js and Tailwind CSS here and there. Bugs: how many? We’ll find out soon. There are a lot of bd(), even db() calls left, deliberately, in the code. Most (all?) have been commented out. They have been left in the code for a reason; to help debug the product. A shop app that you can use incrementally. Many of the features are optional and can be left out (or added later) at install. Inbuilt invoice and PayPal payment gateways/systems. The latter uses V2, the latest PayPal SDK. What not to Expect Although it boasts a rich set of features in its current state, a number of features have not yet been implemented. Some have been implemented but not fully, so may not work as expected. In the expression of interest form I listed the features I’d want to implement next. I asked you to express your preference for these. I’ll be guided by your choices when prioritising the next set of features. Implemented but Incomplete Orders (backend) Manual order creation (creating orders via GUI) is incomplete. Actions including print invoice, mark order as complete, etc are incomplete. Products (backend) Product variants should lazy-load when the product is being edited. Currently, they are all loaded and can slow down the page if they are many. Checkout Settings (backend) Some of the settings including abandoned orders follow-up are not yet functional. General Settings (backend) The settings to limit allowed image and file extensions is not yet synced with the respective image and file fields. Shipping Zones (backend) It is not possible to prevent countries from being added to more than one shipping zone. Shipping Rates (frontend) If more than one shipping rate is matched for a customer for a given shipping zone, it is not yet possible to let the customer select their preferred shipping before finishing their checkout. A side note: matched multiple rates can be desirable in cases you want to offer more than one delivery method to your customers, e.g. a free but slower shipping and a faster but paid-for delivery. Downloads (frontend) Delivery of digital products is incomplete. Not Yet Implemented Access (backend) Access control via permissions and/or roles not yet ready. Other Desirables Not in any particular order and planned for future release(s). Bulk product images management Customer management Discounts Staff management Shipping classes Notifications management Detailed Analytics Additional in-built Payment Gateways (Stripe, etc.). Better management of abandoned baskets Invoice generation and management Known Issues PayPal showing lots of JavaScript console errors. These are all related to CORS as far as I can tell. PayPal struggling with some floats (prices). It will crash and payment will fail. Maybe this could be solved by charging in cents (in PayPal) but I haven’t yet found a way to do this in V2. If you have any questions please ask here. I will contact you later for where and how to report bugs. Please don’t use this thread for that. For generic issues, such as not being able to install, etc., please let me know in this thread. Thanks and happy testing!
    6 points
  21. To be fair it's kind of cheap to blame this particular issue on WordPress. An unrelated vendor was compromised, which is something that could happen to pretty much any platform out there. In this sense ProcessWire isn't much (if any) safer at its core. Just saying. If there's a lesson here, it's probably that "anyone can be compromised". This was a vendor considered trustworthy by hundreds of thousands of users, after all. And perhaps another lesson might be that "relying on third party vendors can be an issue" — although writing every bit of code yourself isn't exactly a silver bullet either 🙂 (In the video above they also put plenty of blame on PHP as a programming language, argue that the issue is due to WordPress being "pretty old" — like new software was inherently more secure than actively maintained older software — etc. There were some valid points there as well, but blanket statements like that... ugh 🙄)
    6 points
  22. @ryan, thanks for this week's updates! @MoritzLost has sparked an interesting discussion about using PW with version control and he makes a comparison with Craft CMS. A couple of excerpts from his comments: Ryan, it would be great to get your voice in the discussion. We're at the beginning of the new year so what do you think about putting better compatibility with version control onto a roadmap for 2022?
    6 points
  23. @elabx Craft CMS 🙂 I'm also trying to move towards static site generator and headless and/or git-based CMS (like Forestry or Netlify CMS). My personal websites are built with SSG and hosted for free on Netlify (processwire.dev & mehrlicht.photos) – though those don't use a CMS at all. But most of the tools for the SSG/Jamstack approach are built to accomodate version control from the ground up. I've been eyeing Prismic, hopefully I'll get a project soon where I can try that out. Though it's hard to find clients for static sites + CMS right now, most have never heard of it … @benbyf Drupal 8/9 has that as well, Configuration Synchronization, but it's a pain to use (like Drupal itself). Luckily I migrated the last Drupal project I had to actively support away from Drupal and to Craft CMS last year 🙃 @bernhard Thanks a lot for the detailed explanation and all the code examples! For the next bigger ProcessWire project, if there is one, I'll be sure to use RockMigrations. Sounds like it solves my problem regarding project schema / config well. But there's still a cost associated with this – every developer needs to know how to use it and not shoot themselves in the foot. How does a new developer install and work on the project from the repository? Is it as simple as composer install, php craft install, npm ci, npm run build? Because every additional step is something we don't have to do when using a CMS with first-party git support. For example, how do you install ProcessWire in this case? Manually? That's work I don't have to do if I can just composer install. Sure, I can hook something up to install ProcessWire using composer scripts on install (in fact, I have done something like this for our starter template which is under version control). But now I have a custom script that I need to maintain, fix if it breaks. Or I put the core in my version control, which means I have to litter my version history with core files. (BTW I could use git submodules but somehow nobody knows they're a thing 🙃) There are more issues like this as I mentioned (e.g. the issue regarding default selected pages in page reference fields; folders containing a mix of files that should and shouldn't be in version control; modules that don't use composer, …). Every one of those can be solved. But every solve either comes with some trade-off (like keeping not project related files in git) or with a maintenance cost and learning curve for a custom solution. And that's a hard sell if there are systems that don't require all that work. Beyond that, I have zero guarantees from the core that all those custom solutions will still work with the next core version (the lack of semantic versioning for the ProcessWire core doesn't help either). There are also side-effects to there not being explicit support from the core regarding those setups – for example, if we want to outsource something to an external developer or train a new hire, we can't just point them to the ProcessWire docs, but have to teach 'the way' to them. For Craft projects, we just follow the standards. Besides the problems I mentioned, there are also advantages that come from the fact that Craft supports version control explicitly and is geared towards it. For example, the production site will not allow any configuration changes (new fields, setting changes, etc) by default. So I have a guarantee that that the configuration will be exactly as I left it so I can deploy with confidence from the repository. With ProcessWire, I don't have a guarantee that nobody has changed some field setting in production while I was on holiday. Of course, not changing stuff in production can be established as a rule, but it's again something to be consciously aware of and enforce, instead of having the system enforce it. I feel like there isn't one single answer to this debate. I hear you – it's easier to complain than work on solutions. Not every project needs a totally 'clean' version control. Trade-offs are acceptable and arguably what we are paid for. I think there's room for multiple CMS with maybe slightly different focus. Right now I'm in the planning stage for a new ProcessWire project that I'm looking forward to. It's just a matter of using different tools depending on the job, no need for a single CMS to rule them all 🙂 Not sure I understand the problem; with Craft, the project config is always the source of truth and the interface is just window dressing to edit the project config. If you're using external modules, they have to be built to support project config, but most plugins are by now. I have said that myself 🙃 After having supported a larger project with regular updates for a while now, which is a bit of a pain. Maybe it would go better if we'd used RockMigrations from the start! Hindsight is 20/20 … @Robin S I'll try to get around to that comparison between Craft CMS and ProcessWire, which would include all the issues regarding version control. But knowing me and my tendency of feature-creep for articles that might take a while 😆
    6 points
  24. Padloper 2 documentation can be found here. This is WIP but has the very least to get your started. It is a bit rough around the edges. We'll improve it as we go along. At the very least, I suggest you read these sections: Getting Started API, especially the finder, cart & checkout and session order chapters. Frontend. With respect to the API, the most important thing to know about is the $padloper global variable. It is your gateway to nearly everything (finding things, carts, checkouts, orders, etc.) in Padloper (2). Please do let me know if you find any errors. I am also working on the starter (demo) site repo. This and the docs should hopefully help move you along. If I get a minute, I might throw in a quick demo video. No promises though 😉. Happy reading 🙂.
    6 points
  25. Yes <?php $rm->migrate([ 'templates' => [ 'car' => [ 'fields' => [ 'title' => [ 'label' => 'Name of the Car', 'columnWidth'=>50, ], 'km' => ['columnWidth'=>50], ], ], ], ]); voila. fields "title" and "km" will be 50% width in the car template context. the title field will have a custom label on the car template. It's really that simple most of the time! Change some properties, commit, push, done! What are you missing? Depends. Both are possible. RockMigrations is really also great if you add it later on a project that did not handle migrations before. It really does not care. For example you could add this in your ready.php: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); // add field test to home template after the title field $rm->addFieldToTemplate("test", "home", "title"); You'll have your test field right after the title field of the home template. You can do the same for everything you add to your site. Doing it like this, of course, the migration will run on every page request. The great thing about the migrations is that this will just work! It's not ideal of course, but I just want to show how it works. Add another field? Here we go: <?php $rm = $modules->get('RockMigrations'); $rm->createField('test', [ 'type' => 'text', 'label' => 'Testing RockMigrations', ]); $rm->createField('test2', [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ]); $rm->addFieldToTemplate("test", "home", "title"); $rm->addFieldToTemplate("test2", "home", "test"); Now we got two fields. Ok, we want those fields in a row? Lets refactor this (it would be possible using the syntax from above as well, but I just prefer the array syntax as it has everything in place): <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Commit, Push, Done. So do you really think manually creating those fields was quicker? Even if you create those fields remotely first and then pull a DB dump and you have at least semi-automated the process and a dump takes "only 15 seconds or so"... I bet migrations are quicker, more versatile, more powerful. Let's say you want to tidy up your project a little bit. Let's add tags for those two test fields: <?php $rm = $modules->get('RockMigrations'); $rm->migrate([ 'fields' => [ 'test' => [ 'type' => 'text', 'label' => 'Testing RockMigrations', 'tags' => 'RockMigrationsTests', // <----- add this ], 'test2' => [ 'type' => 'text', 'label' => 'Testing RockMigrations again', 'tags' => 'RockMigrationsTests', // <----- add this ], ], 'templates' => [ 'home' => [ 'fields' => [ 'title' => ['columnWidth'=>33], 'test' => ['columnWidth'=>33], 'test2' => ['columnWidth'=>33], ], ], ], ]); Thats it! Both fields live under that new tag: Nice and clean! Ok, now let's remove those changes: The IDE will help you find the right method... So we can do: /** @var RockMigrations $rm */ $rm = $modules->get('RockMigrations'); $rm->deleteFields("tags=RockMigrationsTests"); $rm->setFieldData("title", ["columnWidth"=>100], "home"); How long would it take you to delete those two fields manually? Making sure that all checks are met ("you can't delete this field... it is used by XX templates..." *#*&!), going back to the templates editor, removing the field first, then deleting the field, then going back to the home template and setting the title field back to 100%... I don't know the exact workflow - I haven't done that for a long time now 😄 Yeah and we are not even talking about doing those changes in a team... Have fun 😉 Yeah, @adrian, I know Tracy can help. Just trying to show how quick you can get when doing things using RockMigrations. Of course there are some situations where you might not know the properties you need to set. But Tracy can help you. Or you inspect the inputfield and lookup the name in your devtools. The nice side effect: You learn a lot about PW and you will understand it a lot better and improve even more. Well... I don't know what more to say. I feel your pain, but I don't really understand why there are many here "complaining" about those missing features of ProcessWire but nobody seems to be using RockMigrations or seems to have given it an hour or two to simply try it out... 🤷‍♂️ PS: I know the example runs migrations on every page request, which is not ideal. You can come up with your own strategy to prevent that or you can simply use $rm->fireOnRefresh() so migrations will only fire on modules::refresh I'm maybe similar. There's not a single new project not using RockMigrations and custom PageClasses now. It might be overkill for some, but I think for people that are asking questions that you are asking RockMigrations is just the right tool and you are missing something. That would be a pity. We need more people like you here 🙂 Sometimes life as a developer is hard. But we get paid for that 😛😉 I agree on that. I'm working on it and I wished more were doing so 😉 Why not? I agree it's not perfect, but I've put hard work into making this possible over the last years. And I think I've come very far. I don't know much other systems though, so I might be on the wrong track. If you know any better systems I'm just as happy to hear about them as @adrian
    6 points
  26. What ever lived before dinosaurs, I'm one of those 🙂 I use Nova as Code Editor which has a FTP-client builtin. Most of the time I'm working on the live-server. ProCache takes care of my scss-files Modules: PrivacyWire, Jumplinks, ProtectedMode, lot of the ProModules, … ProfileSiteExporter for moving Sites I also do not offer hosting Even with a limited setup as mine, there is a lot possible with ProcessWire. What a great CMS and community. btw: Happy new year to you all!
    6 points
  27. I wanted to update this thread because I had to solve some unexpected problems when importing my content. Maybe documenting this will save someone else the struggle—even me, if my memory fails and I search the forum for answers to the same question. Firstly, my site requires multi-language URLs, and titles. This requires some deliberate configuration with the multi-language modules that must be taken care of BEFORE attempting to import data. This seems obvious in hindsight, but I assumed that these features were enabled by default once the core Multi-language module was active. One thing I noticed when attempting to import data was that the setLanguageValue() method would not work for the name field, even after enabling multi-language URLs. I had to do a lot of searching the forum before finding out that the language-specific name fields have a different way of assigning values via the API than what I could find in the Multi-language documentation. In the end, using the API to assign appropriate data to the fields in ProcessWire required two incantations that I failed to find in the Multi-language docs: In order to make the non-default language(s) "active", I had to use the page()->set() method to establish a hidden property "status$language". This property did not appear as unset when I buffer dumped the page() using TracyDebugger. Assigning the URL title (commonly called the "name" in ProcessWire) in the non-default language(s) required using the same set method to establish a "name$language" property. Here's a stripped down, abstracted example of my working import script, so far. <?php namespace ProcessWire; $en = languages()->get("default"); $es = languages()->get("es-es"); $articles = = database()->query(" // Magic SQL query here "); foreach ($articles as $article) { $parent = pages()->get('/' . IMPORT_SECTION); $template = templates()->get('my-article-template'); $newArticle = pages()->add($template, $parent); $newArticle->set("status$es", 1); $newArticle->title->setLanguageValue($en, $article['Title_en']); $newArticle->title->setLanguageValue($es, $article['Title_es']); $newArticle->name = sanitizer()->pageName($article['url_title_en']); $newArticle_name_es = sanitizer()->pageName($article['url_title_es']); $newArticle->set("name$es", $newArticle_name_es); $newArticle->body->setLanguageValue($en, $article['Body_en']); $newArticle->body->setLanguageValue($es, $article['Body_en']); // Etc., setting each field's value using setLanguageValue() method $newArticle->save(); } I have moved on to other aspects of the project, but I wanted to post this before I forget. It makes me wonder what else I'm missing out on, and how I might learn to do this better. Thank you!
    6 points
  28. Some of you might of used my previous U2F module for their two factor needs. Well I was recently informed that Chrome is dropping plain U2F support in favour of WebAuthn. So after a full day of debugging some cryptic errors I am proud to announce a WebAuthn module. This has some major improvements. For example you can now use on-device credentials like Windows Hello/Apple Touch ID. This means that even people without a Yubikey can benefit from modern two factor authentication. It also has much better cross platform support. For example NFC will now work on an iPhone. I do not recall the original U2F stuff working well on iPhones so yay? The is still the original issue that ProcessWire imposes with its Tfa class, That being it is a setup once and never edit again system so you can only add your on-device credentials for a single device because once saved you cant then edit your credentials on a second device. You also lack the options to revoke a single credential or add a new one. You have to wipe out the config and re-add your keys again. It sucks but realisticly if you need more than 3x credentials your almost defeating the point of Tfa I feel the need to also point out that this does not replace passwords. That is something WebAuthn can do a fully passwordless setup. But I think implementing that inside ProcessWire would be a huge challenge. It is frankly a form of magic that I was able to make WebAuthn work within the confides of ProcessWire's Tfa class. Github: https://github.com/adamxp12/TfaWebAuthn ProcessWire Modules: https://processwire.com/modules/tfa-web-authn/ I hope this module helps you guys out securing your ProcessWire websites If you have any issues just reply and I will do my best to help you out
    5 points
  29. Hi Roy, welcome to ProcessWire! ProcessWire likes to remain “markup agnostic”, so it won’t really “generate” this sort of thing for you per se. This leaves you flexible to set up your site the way you deem best. For the carousel you would want to use a javascript solution such as Swiper.js or Slick.js. Whatever you choose will probably have its own expectation of what the markup should look like. On the ProcessWire side of things, it can be as simple as creating an multi-image field for your homepage template and uploading some pics. Outputting the markup for those images is very easy with PW, and PW will help you make sure the images are the right size, aspect ratio, compression and so on. It’s also great for managing further information about the images, such as textual descriptions, licensing info or links. Anyway, depending on your requirements, it obviously doesn’t have to be images from a multi-image field. ProcessWire makes it just as easy to have a carousel of each of your site’s subsection’s main image, or something. Or no images at all. The hard part then is making sure the javascript slider you chose interacts well with the rest of your site and works responsively. These frontend concerns are outside of ProcessWire’s scope. The other thing also depends greatly on your requirements. If you just want some testimonials on your homepage, you might use one of the multi fields (eg. the Repeater field). Editors will be able to add as many customer quotes as they like, and your site might randomly show some number of those. Again, ProcessWire’s role here is to help structure that data and make it accessible to your frontend code, but the HTML and CSS are up to you. Since you mentioned the ProcessWire homepage, I noticed each item has a link to some other part of the site for more information. There are plenty of ways to achieve this and you’ll have to pick the one that’s best for you and your client. ProcessWire’s homepage not only links to various pages but also to specific sections on those pages. Using the central repeater I suggested above, you might add a url field to the repeater and fill it accordingly. This gives you the most freedom: you can put anything in there, even an external link to Youtube. It’s also the worst user experience for your client, who now has to copy and paste stuff from the address bar around (it’s also error prone for this reason). Another option would be to use a page reference field. Now you’re bound to pages on your site and you can even control specifically which pages may be chosen. This will also enable you to select all pages that are referenced on the home page, if you ever need to. Pretty solid. An entirely different approach would be to store this information not on the home page at all, but on the detail pages themselves. You could have a couple of fields on every single page (“attentionblock_title”, “attentionblock_snippet”…) and if they’re filled, you show that page on the home page. It might even be a just checkbox.
    5 points
  30. Side note @ryan it would be nice if you could add relevant keywords to the title of new news or blog posts. This makes it easier to find information when you are searching for it weeks or months later ("weekly update 14.1." is not nearly as helpful as "weekly update find raw parents, sanitizer float" in a search result) +1 for better version control support. I've not built RockMigrations just for fun 😁
    5 points
  31. Very good points there and definitely a big thumbs up for this topic in general, but not sure if I can fully agree with this part: Any module that supports Hari's composer installer, Wireframe composer installer, or the official composer installers package will automatically be installed in the correct directory. Technically only requirements are that the module includes composer.json, and is marked as pw-module or processwire-module. If you're using a custom directory structure (like we do), you'll indeed need a config setting in your main composer.json to specify where your modules directory is located — but even then it's a once-per-project thing. Hari's installer doesn't support this but others do, and Wireframe installer will also automatically detect any module's using Hari's installer and override it to make this work. On a loosely related note, in case module authors are reading this: Hari's installer may still be the most popular option, but it's somewhat outdated. It lacks support for Composer 2, doesn't provide any configuration settings, etc. I would strongly recommend moving to more recent (and actively maintained) alternatives. I always add the modules directory to Git ignore, so it's definitely doable. This works out of the box for composer installed modules, and modules that are not installed via composer can still be added to the repository with the -f flag, which essentially makes Git ignore the ignore rule. Only problem would be modules added in a production environment via GUI, but since we're talking about version controlling stuff, this doesn't seem like a particularly relevant concern to me. In case of modules that don't support Composer installation, creating a private fork is of course always an option. This works nicely for commercial modules as well, but requires installing said modules via Git repository (which is a bit clunky), or via private Packagist (which is more elegant, but requires paid plan.) In my setup ProcessWire is installed and updated via Composer. Again doable, but this part could admittedly be more elegant: since the wire directory needs to be in a publicly accessible location, typically you'll need post-install-cmd/post-update-cmd in your composer.json (or something similar) to move / copy said directory from vendor to another location. Anyway, would definitely like to see this topic getting more attention in future releases. And it would of course be great if more module authors would add their modules to Packagist — that would make things easier for Composer users, and setting this up is quite straightforward. 🙂 In WP plugin installs via Composer are — for the most part — solved by wpackagist.org, which mirrors all plugins in the official plugins directory. In a nutshell this means that plugin authors just need to submit their plugins to the directory, and they automatically become installable via Composer (composer install wpackagist-plugin/plugin-name). Having something like that for PW would be an interesting option for sure.
    5 points
  32. Assumes "categories" is a multiple Page Reference field and that you have a hex colour defined on each category page: $wire->addHookAfter('ProcessPageListRender::getPageLabel', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'accommodation') { $out = ''; foreach($page->categories as $category) { $out .= "<span class='uk-label' style='background-color:$category->hex_colour'>$category->title</span> "; } $out .= $page->title; $event->return = $out; } });
    5 points
  33. /site/modules/MyModule /site/modules/MyModule/classes /site/modules/MyModule/classes/MyPageClassOne.php /site/modules/MyModule/classes/MyPageClassTwo.php /site/modules/MyModule/MyModule.module.php The module: <?php namespace ProcessWire; class MyModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'MyModule', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->rm()->initClasses(__DIR__."/classes"); } /** * @return RockMigrations */ public function rm() { return $this->wire->modules->get('RockMigrations'); } } The class: <?php namespace ProcessWire; class MyPageClassOne extends Page { public function init() { $this->wire->addHookAfter("Pages::saveReady", $this, "onCreate"); } public function onCreate(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof self) return; if($page->id) return; $page->status = 1; // auto-publish this page $this->message('Auto-published page '.$page->path); } } initClasses() will not only load your custom page classes but also trigger the init() method once. That makes it possible to attach all kinds of hooks that belong to the custom page class where they belong: Into the page classe's php file. You avoid hook-hell in ready.php like this. It will load one instance of your page class on every request though. You can also use custom namespaces easily: // in the module: $this->rm()->initClasses(__DIR__."/classes", "MyNameSpace"); // your page class: <?php namespace MyNameSpace; use ProcessWire\Page; class MyPageClassOne extends Page { ... } You don't need to use RockMigrations for that. You can have a look what initClasses() does. You could also just set the page class on the template. I don't know if that can be done manually but using RockMigrations it is just setting one property of the template: 'my_template' => [ 'fields' => [...], 'pageClass' => ..., ]
    5 points
  34. ProcessPageAdd preselects the template according to these principles: If there is already one or more child pages under the parent then it preselects the same template as used by the most recently added child page. If there are no child pages it preselects the same template as used by the parent page. But if that template isn't allowed to be used under the parent page then no template is preselected. So probably you recently added a page using the template that is only used in 5% of the cases, or that is the template of the parent page. You can force a particular template to be preselected in a couple of ways. 1. You can add a "template_id" GET variable to the URL of the "Add New" page. Example: "/processwire/page/add/?parent_id=1234&template_id=29" This might be a good approach if you are constructing your own custom link to the "Add New" screen but not so useful if you are just adding a new page via the standard PW admin. 2. You can use a hook in /site/ready.php to set a template_id GET variable to $input: // Before the ProcessPageAdd form is built $wire->addHookBefore('ProcessPageAdd::buildForm', function(HookEvent $event) { $input = $event->wire()->input; // Get the parent page the new page is being added under $parent_id = (int) $input->get('parent_id'); $parent = $event->wire()->pages->get($parent_id); // Return early if a single parent page isn't available or valid if(!$parent->id) return; // Do whatever check you need to identify if this is the parent you want to target if($parent->template == 'home') { // Get the template you want to be preselected $child_template = $event->wire()->templates->get('basic_page'); // Set the template ID to the "template_id" GET variable $input->get->template_id = $child_template->id; } });
    5 points
  35. I'd love to know your favorite PW alternative - if something else exists with all the features, flexibility and ease of PW which also has full compatibility with version control, that would be perfect. Surely it would require a flat file database, but even that has its problems when it comes to data querying, doesn't it?
    5 points
  36. Thanks everyone for the insights! Nice to see all the different approaches, and that I'm not the only one struggling to find a 'perfect' solution … @bernhard Thanks for this. Look real close to a version-controllable schema config. Can the array syntax for fields/templates handle field overrides in a template context as well? What about settings that are environment-specific, like specific parent pages in page reference fields? How would you approach an existing site that doesn't use migrations – add all the existing fields to one big migration file? Or include a database dump as the base state and perform all further changes in the form of migrations? You're right, doing everything manually is a pain. But handling everything in code is a pain as well. The problem for me is that too many areas of ProcessWire are not built with version control in mind. Migrations solve field/template configuration. But then you need to keep track of installed modules, if you want to install modules with Composer you need custom config so they're installed in the right folder. Of course you can't put the entire modules folder in gitignore, since site-specific modules go into the same folder. And what about ProcessWire itself, I don't want the entire core in my version control. So again, custom download script. The list goes on. You don't want to keep track of uploaded files, so the asset folder goes into gitignore. But I do want translations in my version control, turns out those are in random directories in the assets folder … the list goes on. There are just so many small issues if you want a 'complete' version controlled ProcessWire site, which to me means (1) the site can be rebuilt completely from the repository alone and (2) there's no external code or dependencies. And if you solve all of these with scripts, those become hard to manage and even harder to enforce in a team … not sure where I'm going with this to be honest 😅 I'm a bit of an all-or-nothing person, if I can't have 'clean' version control I'd rather not have version control at all. Probably unwise. To be honest, for new projects I'm currently settled on option 3: to not use ProcessWire at all, unless the project won't require any significant updates after launch. Even all the problems mentioned above can be solved one way or another, it's just not worth it compared to other systems where I get full compatibility with version control by default. I don't think this will change as long as ProcessWire doesn't support version control natively. @horst Yeah, that's close to what I'm doing for updates as well. As long as you're keeping track of any field/template changes diligently, it's not too much work. Though it still bugs me doing the same thing twice. And of course it doesn't solve the problem of working on an update with multiple people at the same time. @szabesz We do that for significant updates to older projects where we don't have development versions any more. Though it means the client can't edit anything while updates are being done, and it doesn't work for sites with user-generated content or user accounts where you can't just freeze the live database for a larger amount of time … @elabx So all your sites are identical in feature set? That definitely doesn't apply to our projects 😅 The point regarding bitbucket pipelines is interesting. Though I'm hesitant to use automated deployments if I have too write too much custom logic for it or mix partially automated deployments with manual steps. Too error-prone and difficult to enforce in a team, in particular if you want to work on site updates with multiple people …
    5 points
  37. Once my PRs are approved the latest version of this module will make it possible to set the main color via an inputfield:
    5 points
  38. Real programmers use butterflies To everyone using git for automated deployments: How are you handling field/schema changes in between environments? And what about module updates/new modules, module configuration, custom module data (like Hanna Code shortcodes)? And everything else that's in the database but affects the CMS, like selecting a specific page as allowed parent in a Page Reference field? A database dump is of course an option, but once a site is live you can't just import the dump in production since it will overwrite the live contents. Are you writing migrations using one of the migration modules by hand? For every single field, field setting etc? Assuming you're able to handle all the edge cases (mentioned above and otherwise) with custom migration code, isn't that hugely time-consuming? Particularly when it comes to creating complicated field setups like Repeater Matrix fields with multiple types, where some settings are stored separately from the field settings and not all properties are documented or type-hinted … Something else? Anyone got a setup that allows them to use git and deploy from dev to staging/production without manual steps? If so, how are you handling the above issues?
    5 points
  39. I wish everyone a good start into the new Year. To round up this year I released v0.10.0. The library is runnable as intended in a ProcessWire Environment and fully testable in Standalone mode for developing. Symprowire Release v0.10.0 - Backpain I will publish a demo implementation next year. Hope it will be of use for some of you guys.
    5 points
  40. @Jonathan Lahijani - I love it - your comments have a very similar tone of ridiculousness that my list has :) Firstly, I am glad you found Forklift - I use it exclusively and I actually love it for FTP because I can open files directly from a remote server into my code editor and saving the file will send it straight back to the server. Obviously the dual pane is essential, especially given the stupidness of the cut / paste situation. The other crucial thing it has for me is being able to order folders first, and then files - that is truly the dumbest thing in MacOS. The Enter to rename drove me crazy for a while too, as did not being able to delete a file by hitting the delete key - don't even get me started on the lack of an actual delete (vs backspace) key on laptop keyboards :), but I am mostly over that now. These days I only use the trackpad (because damn they are nice on macs - pity the magic mouse is garbage), so the acceleration stuff doesn't bother me, but I can imagine. Oh, and yes to the window focus stuff - definitely annoying. Another utility you should try is BetterTouchTool - it has lots of mouse / trackpad settings, along with window features like snapping, but most importantly bringing proper window maximizing (rather than full screen) with the plus icon. Regarding having Finder first on the dock - I almost never use the dock because I have Alfred, so app launching / switching is with the keyboard. You might also like to try Hyperswitch for a more Windows like dock. Anyway, despite all the bad UX stuff, I generally do find it much more stable and it's amazing to have not reformatted / reinstalled the OS once in 10 years. I also love the unix basis to the OS - I know there is now WSL, but it wasn't around when I was using Windows.
    5 points
  41. Funny you say that because I wrote a similar list as well. Here it is with some added commentary. As you can see I solved some things but listed them anyway and other things I didn't list because I solved them. general when clicking something in an unfocused window, the first click will focus the window; another click must be made to actually do something in the window I didn't realize how much this annoyed me. I thought Front and Center fixes this but it doesn't. finder (and Finder replacements) can't move or even remove the finder icon in the dock I don't want Finder to be first; to counteract, I've added a bunch of spacers so it's visually separated from my core programs (vscode, chrome, forklift, iterm) there is no "cut" option in finder (must copy, then use the move/paste with command + alt + v -- requires 2 hands) can't have custom categories in finder (just favorites, locations, icloud and tags) can't have the main folders load from a custom location like you can in windows; must use symlink instead this messes up how Finder search works hitting 'enter' on a file or folder does rename instead of launching the file / entering the folder (naturally, 'enter' seems like the right key to hit to ENTER a folder, not rename it) this means i have to use whatever the keyboard shortcut macOS wants you to use, and I don't remember what it is, but I remember I must use 2 hands -- ridiculous! the files list does not refresh automatically if a new file was written somewhere else (!) I use ForkLift as a replacement to Finder, but nothing in the macOS ecosystem comes even close to XYplorer (I used that for 13 years and it's updated constantly; it's like the ProcessWire of file managers... a Swiss Army Knife) mouse mouse wheel uses acceleration which makes sense for touchpads and mice without an actual WHEEL; it's not linear like you would expect counteract with https://github.com/emreyolcu/discrete-scroll the fact that macOS uses acceleration based scrolling for notch-wheel mice is ridiculous. that doesn't make any sense. macOS mouse movement physics is weird (at least compared to Windows) using outdated steelseries exactmouse to counteract that program is from 2010 (!); there's nothing more recent! no middle-click + scroll use "AutoScroll" extension in Chrome; it doesn't have the same feel like in Windows chrome can't open a new tab inside a chrome app like you can in windows; must first focus a regular chrome window other software Transmit (the SFTP client) doesn't support folder bookmarks (really wish it did so I don't have to use FileZilla; I don't want to use ForkLift for SFTP)
    5 points
  42. @Richard Jedlička @wbmnfktr You can set a response code in your hook like this: http_response_code(400); So you can set 400, 307, or whatever you need. https://www.php.net/manual/en/function.http-response-code.php
    5 points
  43. Sorry about that, I've pushed a fix for that issue. Thanks.
    5 points
  44. M1 Mac Mini My first Mac. I love the hardware, but macOS is just not for me and it does some idiotic UX things that I can't stand, to the point where it's become a deal breaker. May go back to Windows and keep this as a second machine or just switch to Linux (Fedora KDE most likely); will probably stop using WSL2 and set up a dedicated Linux server for development (I don't like working with virtual machines). LAMP stack (installed and configured everything with Brew); everything ARM-based VSCode with various plugins ProcessWire with various modules (Profields being a must) + my super module (still developing it; lot's of breaking changes until the dust finally settles) I too set up a $config->env variable Laravel Mix for frontend asset management Hosting: DigitalOcean with Ubuntu Server (but considering Fedora Server in the future)
    5 points
  45. The JSON that this feature generates for import/export mostly works for me, however the issue is having to manually select fields/templates via the UI. I notice that templates include a timestamp for when they were changed in the data field of the templates table, but fields don't. If both did, then it should be possible to get fields and templates that have changed since the last build time of a module or template. I use the admin UI, and don't want to write more code than I have to. Specifying what fields and templates that a module depends on in code and letting the system pull a config file with the definition of those fields and templates from the database would be UI friendly, but not rely on having to remember what fields or templates are required for a specific purpose, but not require much code either. This is similar to a database first workflow I have with SQL Server and ASP.Net Core. I can reverse engineer any tables I want from SQL Server to get a class definition, so I don't need to worry if the definition of something was manipulated outside my code; I can always grab the current definition without having to write any code. For those who have a licensed copy of Padloper 1, it's interesting to see how it creates the fields and templates it needs. It appears to be using JSON files based on the field and template import/export feature, but has its own code to import them. With a timestamp and possibly a version number added to the data in the fields and templates table, I wonder if that would make a hybrid UI/code based update model easier to work with? Of course for more complex migrations, RM is more capable, but I wonder if even there, it can grab the field and template definitions if they're exported as JSON?
    4 points
  46. @guy You could try this: if($this->wire()->process == 'ProcessPageEdit') { // save from page editor } If you want to capture other types of page editors, like ListerPro, User Profile, etc. you could do this: if(wireInstanceOf($this->wire()->process, 'WirePageEditor')) { // save from any page editing process }
    4 points
  47. thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity. What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example: <?php namespace ProcessWire; /** @var RockMigrations $rm */ return [ 'fields' => [ 'foo' => [ 'type' => $wire->languages ? 'textlanguage' : 'text', ], ], 'templates' => [ 'demo' => [ 'tags' => RockMails::tags, 'fields-' => [ 'title', 'foo', ], ], ], ]; That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML. I'm really curious what it is really about, thx.
    4 points
  48. This is totally freaking awesome! Can't give enough thumbs up. Any plans to release this? Wannahave 🙂 That would just be such a great help for keeping things in sync.
    4 points
  49. ATM I simply use the manual export <> import function from PW for fields and template settings. Every time I also have to alter field and or template settings, I write down the timestamp on a pad of paper when I start to do so and then collect a list (on the left side) of all fields I touches in the next time until deployment, (and on the right side I collect all template names).* When I'm ready for deploying, I may or may not shut down the live system for a short amount of time, depending on the amount of changes, then collect from the DEVs export selector all needed fields, copy the export json and drop it into the targets fields import field and proceed. Next step is the same with template changes. There is no need to shutdown a live site for long time. Mostly when I had large deployments, it was closed for one hour, but most of the time I do and have done those db migrations without any maintenance mode, because most of my sites uses ProCache. If it really would matter, I can prime the cache by crawling the site once before starting to deploy. It is not comfortable and also not the best I can think of, but it's not nearly as uncomfortable as described by @bernhard😉 Using these functions is not nearly as error prone as manually writing EVERYTHING into one schema or another for every field and template change. Noting everything by hand is not error tolerant for typos, I might forget to note a value, a change to a template, etc. All this is avoided by simply copy-&-paste ready generated JSON directly from PW. No typos, nothing forgotten, nothing added. Not perfect but for me much faster, easier and safer than writing everything down again by hand. PS: * In case you are not sure if you have written everything down on paper, you can generously include additional fields or templates in the export. In this case, it is better to have more (or even all) than too few. All unchanged settings will be recognized by PW during import and will not be processed further. 🙂
    4 points
×
×
  • Create New...