Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/31/2022 in all areas

  1. Last year I started working with Craft CMS, a CMS roughly similar to ProcessWire in scope and target audience (developers). Since I like Craft a lot and found it has some great solutions for problems I had with ProcessWire, I wanted to write up a comparison between the two systems, point out similarities and differences. This is also intended to introduce some ideas that ProcessWire could benefit from. Admittedly, this comparison is a bit unfair – ProcessWire is completely free and open source, while Craft CMS requires a paid license for everything but very small projects. So while Pixel & Tonic, the developers behind Craft, can fund an entire team to work on Craft and developer support, ProcessWire is mostly maintained and developed by one person. Still, I think the comparison is worthwhile, since it could help focus development on the areas where ProcessWire (in my opinion) needs improvements the most. Disclaimer: I'm not associated with either ProcessWire or Craft CMS (Pixel & Tonic), and I'm not being paid for any of this. Pricing A regular Craft license for a single site is 299 $ in the first year, then 59 $ / year for updates (this is optional). If you don't need multiple user accounts and some optional CMS features, there's a free version as well. There are also premium plugins which come with licensing fees. There's no bulk/agency pricing, so you have to include the license fees in the calculation for every project. ProcessWire is completely free, though there are the commercial Pro modules. Some of those are required for almost every site, in particular ProFields (for the Repeater Matrix), so the average site probably won't be completely free. Those modules are available as agency licenses, so for agencies with lots of ProcessWire projects they are a pretty good deal. Content modeling Both systems are quite similar in this regard. You can create fields (chosing from a variety of field types) and create content types with any number of fields. ProcessWire calls content types templates, Craft sections – sections can further be divided into different entry types with different fieldsets. ProcessWire puts everything into a single page tree / hierarchy. This is handy in some situations, but all in all detrimental. First, you have to fit everything into a page hierarchy, even pages and content that don't have a natural place in the tree. This makes it harder for clients to find what they're looking for. Also, you're heavily incentivized to generate your site navigation based on the tree hierarchy, which is bad in the long run. Craft instead has top-level index views (in the backend) for every content type – entries, categories, users, etc. You can organize entries in a section in hierarchies or streams, depending on what makes sense for that content type. Craft also has a media library where you can upload assets independent of pages. ProcessWire doesn't allow you to do this. I'm actually fine with that, though many clients care about this for some reason. Interface Both ProcessWire and Craft have mostly nice, usable interfaces. The editing interface of Craft feels a bit cleaner and more modern due to being more restricted. ProcessWire opts to have lots of display options (and even replacable admin themes), which is handy in some situations. Craft is more streamlined, which makes it feel more coherent. Both approaches have their merit. Craft is actively working on improving accessibility and has a stated goal to be accessible. Meanwhile, ProcessWire at the moment doesn't make any claims regarding accessibility, and ryan seems to be actively opposed to the idea. Templates & Theming Both ProcessWire and Craft are developer-centric in that you have full control over your HTML output. Both systems have starter projects in lieu of themes, allowing you to start with a project template and customize it as you go, or start from a completely clean slate. A major advantage of Craft is the Twig integration which it provides by default. This is a contentious topic and I don't want this to turn into a debate of plain PHP templates vs. template systems. But Twig just has some advantages that plain PHP doesn't: Block-based inheritance is impossible in plain PHP, and without that you can't have fully extendable base templates without those base templates having knowledge of ALL extending templates or being so granular that they stop being useful. Twig forces you to separate logic and presentation, putting your business logic in services and/or controllers. All the other benefits that are always brought up in discussions about Twig, like security by default, simpler templating syntax etc. You can include Twig in ProcessWire, though it's a bit of extra work. And Craft's Twig integration goes much deeper, providing many useful functions to templates. For example, there's a cache tag that 'just works' (99% of the time) and allows you to cache parts of your template output. With ProcessWire, you have to use the $cache API manually and take care of cache keys, cache invalidation etc. Developer API & data access Both ProcessWire and Craft provide a strong API to query for content / data. They are actually quite similar in that you can query by content type or properties, search for field values, apply custom ordering etc, everything you would expect. One downside of ProcessWire's API is that it's string-based (there's an array alternative, but that isn't super reliable and not well documented). This means that you have to take care of input sanitization to prevent query injection. Craft's element queries use method chaining instead, which means you have better separation between query and data. This way, the the field type classes are responsible for sanitizing their inputs before adding them to the query, so you mostly don't have to escape user input manually. One downside of element queries in Craft is that they're quite hard to extend. Though that's to be expected because those queries support a lot more native features (multi-site support and expiration dates, for example). Multisite support Craft provides full multi-site support while ProcessWire doesn't. There is a third-party module for ProcessWire module, though that comes with zero guarantees that it will continue to work and is much less convenient than the built-in multi-site support. Not really an issue for sites that don't require multi-site capability, but a gamechanger for sites that do. Internationalization & localization Both systems support code I18N, and both support multi-language setups. Interace translations in Craft can be included as simple PHP files, though there are modules that extend this to provide an editor interface for string translations. ProcessWire does provide an interface, but it's clunky and heavily developer-centric, requiring you to chose files from a list, so you can't really ask clients to use it. ProcessWire also uses file scanning to detect translatable strings, which means you can't use it with custom setups (in particular, it's impossible to use with Twig). Finally, you can't really bypass the interface since translations are stored in JSON files in, essentially, random locations, so adding translations directly in the code editor is impossible. Field translations in Craft work with all built-in fields and all module fields and are well integrated into the developer API. ProcessWire's field translations suffer from the fact that they seem tacked on and not well thought out. For example, regular text fields can be translated inline. But if you want to translate an asset field, you need to add the second language's field manually, which feels weird and looks bad and unintuitive in the interface. Custom development Craft is built with Yii2, which most people will agree isn't the best PHP framework there is. But it does integrate nicely into Yii2, and you can also bypass them and build specific features using Yii2. The framework provides standard components for models and validation, controllers, views, etc. With ProcessWire, everything is homegrown. This makes it easier to get started at first, but hinders you in the long run, because there just aren't as many utilities, best practices and components to use for custom development. Oftentimes, you're either completely on your own, or have to dig through old forum posts and blog articles to find details (sometimes unfinished) features. Building custom features into ProcessWire isn't really encouraged or supported as ryan confirms here. Roadmap and feature policy Craft has a limited feature set, but supports those features well. Things like multi-site support, translations and live preview are built into the system from the start, provide strong APIs and all of those features work with each other. They also provide a roadmap so you can see what new features are coming next. All in all, Craft development seems organized and focused on their target audience. ProcessWire's feature approach is a bit … chaotic, to say the least. New feature seem to be added whenever ryan thinks of something cool to add. The problem is that most of those feature are never completely thought out and are quickly abandoned. There's hundreds of features that look cool but just aren't well supported – they lack documentation except for old blog posts, they have bugs that never get fixed, they don't work well with each other and so on. A much more limited feature set that can actually be supported with documentation, support, integration with other features would be preferable by a long shot. Documentation The Craft documentation is clear, well organized and provides a good overview of the system as a whole. It's It does lack a bit in depth, so for custom development you often have to look through the source code to find what you're looking for. There's also a generated and searchable class reference. ProcessWire's docs are also helpful in general, though they lack a clear structure and hierarchy, making it hard to read it back to back or find specific pieces of content. Its also missing most of the features that get added on a weekly basis – see the point above. This means the only way to discover or find info on those features is to root through old blog posts. Semantic versioning Semantic versioning is crucial for peace of mind come update time, so developers know whether an update contains bugfixes, new feature and/or backwards compatibility breaks. Craft, up until version 3, doesn't follow semver closely. The first digit (3) is reserved for marketing, while BC breaks are delegated to the second digit (e.g. Craft 3.6 -> 3.7). Bugfixes and compatible feature additions are lumped together into the third digit (though curiously, sometimes they add a fourth digit for urgent bug fixes). But starting with Craft 4, P&T will switch to full semantic versioning, so every BC break will bump the major version number. ProcessWire uses the first digit for marketing as well (ProcessWire 3). Unfortunately, it doesn't use the second digit at all, so we're still at 3.0.X years after the first PW3 release. And the third digit is just incremented whenever there's a couple of commits that need releasing, so it doesn't have any significance beyond the ordinal scale. This makes it impossible to know if a given update will cause problems for you. Ryan has stated somewhere (can't find the link) that this is because there haven't been any BC breaks since version 3.0.0 so far, which is … not true. At some point, an update broke the ability to upload SVG files to asset fields if you don't have the FileValidatorSvgSanitizer module installed. If this isn't a BC break, what is? Terminology This is a minor point, but it bugs me. Both Craft and ProcessWire have terrible terminology. Without looking, what do you think a section is in Craft? ProcessWire meanwhile overloads the term template to refer both to content types and the PHP files for those content types, making it really hard to talk about those. Have fun if you're using Twig as well, now there's three distinct things that are all called templates. ------------ I wanted to talk about version control as well, but this post is already a mile long, so that's gonna be a topic for another day.
    7 points
  2. There's been a lot of talk recently about managing ProcessWire sites in version control systems (git in particular). Currently, this is quite difficult. The most important reason is that most of the site configuration is stored in the database, which you can't track in version control save for a database dump. But beyond that, there are many features and functions that don't work well with version control. To keep it short, I'll try to list everything I would like to see in terms of version control support in a potential ProcessWire version 4. For comparison, a similar system that does fully support version control is Craft CMS, which is also the inspiration for many of the approaches and changes listed below. Goals and paradigms Version control isn't self-serving, but enables several important development practices and workflows. This includes the following: Having a complete version history for a site, and being able to revert to a specific version or restore earlier versions of specific files and features. Being able to work asynchronously on a project with multiple people, without the need for excessive coordination or a lot of work to merge parallel development work. Having a single source of truth for the entire site (excluding content) in version control. This allows you to: Set up automated deployment pipelines (dev -> staging -> production) with no manual steps required for a deployment. Set up new instances of the site (additional staging environments, new live site if the server burns down, etc) with little to no manual effort. Being able to switch between development branches and instantly sync up to the site state in that branch (especially useful for pull request reviews). Everything on following wishlist will be in service to those goals. The wishlist Declarative config. This is the most important thing. ProcessWire needs a config schema that includes all the fields, templates and site settings of the site, alongside tools to import/export this config. This allows you to modify the site configuration in a development environment and instantly apply those changes to other environments. There's been some discussion about declarative config vs migrations recently, so I'll just quote my points on this debate: More on that in this thread. For reference, Craft provides this in the form of the project config. Split ProcessWire into a starter project and a Composer dependency. ProcessWire is installed the old-fashioned way, by downloading a zip file and unzipping it in the web root. This leaves you with a problem – either include all the core files in your version control, which muddies your version history, or set up custom hooks or scripts to repeat this step during deployments. In addition, a default ProcessWire installation will include lots of directories and files where it's not clear if they belong to the core or are intended to be modified and included in your site repository. This can be solved by splitting ProcessWire into two repositories. One is the actual ProcessWire core, which can be installed as a dependency using Composer. The other is a starter project that only contains a site skeleton and is intended as a starter point for your site's directory. Other site profiles can become alternative starter projects that you can choose from. Craft comes as a starter project (craftcms/cms) which only includes the skeleton for the most important directories and files and installs the actual CMS as a dependency (craftcms/craft). Better directory structures. The current directory structure doesn't separate core files and site files well, and for many directories it's not clear whether you want them included in version control. For example, the site/assets/files folder contains uploads for assets, so you want to exclude them from version control, right? The problem is that for some file go into that folder that you do want to track, so you have to manage that manually. Translation files, for example, go into the assets folder, but you probably want those in version control. Another example are modules – custom site-specific modules go into the same directory as contributed community modules. You want the former in version control, but not the latter. Make modules installable with Composer. Pretty self-explanatory – currently you can only install modules by, again, unzipping folders manually or through the module interface. You can't install modules automatically during deployment (at least not without some custom scripting and workarounds). Making those installable with Composer would solve that issue. This goes for Pro modules as well. Better distinction between content and configuration. To support deployments that update a site configuration to a particular state while leaving content untouched, you need a clear distinction between config and content. This is important if you are developing in your local dev environment while the live site is constantly updated with content. If the site has user-generated content, you can't just import the development database from three weeks ago and call it a day. But for many settings and features it's not clear whether they are content or config. For example, what about multi-language sites – are the available sites content or config? Languages are just pages under the hood, so it looks like they're content – but there are some good arguments to be made for tracking the available languages in version control. Another example are page reference fields. Those allow you to select default pages and limit selectable pages to a specific parent page – but now you have content (specific pages) in your configuration. Those pages might not exist on the target system, so this feature might break unexpectedly in a different environment. For comparison, Craft's project config explicitly defines everything that goes into the config – everything else is content and won't be included in version control or deployments. Provide CLI tools for deployments. Many of the operations you need for a deployment can only be performed through the interface, so it doesn't work with fully automated deployments. To address this, ProcessWire needs to provide a CLI tool to automate those operations. For example, installing modules, synching up the project config (see the first point) and clearing caches need to be automatable. Craft provides a CLI with those and many other commands. Better integration with standard development tools. ProcessWire uses a lot of custom solutions instead of standard tools and practices. For example, it provides a custom interface and installation method for modules, which could be simplified a lot by just using Composer for module installations. By the way, it is possible to provide a user interface for Composer operations, Craft does exactly that. But I don't think this level of polish is necessary. Simply using standard tools and practices that are compatible with version control by default will reduce development time for those features and at the same time be easier to work with for developers. Support for environment variables. You don't want passwords and other credentials tracked in version control, and you want to be able to distinguish between environments (dev, staging, production) to toggle some features or change some settings. The standard way to solve this are environment variables. This way, you keep database configuration, SMTP servers, passwords to external services and so on out of version control and provide custom values for those depending on the environment. Craft, for example, allows you to change all configuration values based on the environment, and disables any configuration changes in production environments by default. Webroot in a subdirectory. This is a minor point and admittedly only tangentially related, but it's a no-brainer once all the other changes are made. The project root should not be the webroot because that makes all project files publicly accessible by default. To fix this, ProcessWire uses a lot of .htaccess rules and .htaccess files in subdirectories, but that only works if you're using Apache. A lot of modern server management tools use other servers, like nginx or Caddy, so those require additional work to secure a ProcessWire installation. The fix here is to point the webroot to a subdirectory (like web/ or public/) and only put files that you want to be publicly accessible in there. ------- All those changes constitute a major shift in mindset and approach, which is why I think they would need to go into a future ProcessWire v4. To be honest, at this point I don't think it's likely to happen, since Ryan has repeatedly signaled that he doesn't see the value in those changes. While there are promising attempts to solve this from the community, true support for the goals outlined above can only come from the core. As long as that doesn't happen, ProcessWire won't be an option for any projects that require more than one or two people working on it or that need continuous development and deployments – at least for me. Not as long as there are other alternatives, like Craft CMS, where I get all those benefits out of the box.
    6 points
  3. Padloper 2 has been released I will write a better post later. Need to know for now: Get it from here. We will be transitioning to a new website and/or shop in due course. For now, please get it from that old site. For now, and to allow it to bow out gracefully, initial purchases will be powered by Padloper 1. All hail Padloper 1 :-). Due to #2, and #3 and due to non-SCA compliance on that particular site, there might be Stripe issues. Apologies. Please contact me for help. Support for Padloper 1 has ceased. Security fixes will continue. Things I have promised to look at will be looked at :-). Support subscription period for beta testers' purchases commences today - 30 March 2022. It is a special day...in more than one way... Update 3 April 2022 Frequently Asked Questions A few questions are coming up with respect to this release. For now, I'll answer them here but might start a new threaded dedicated to FAQs. Q: Will beta testers have to purchase a new licence for this release? A: No. Your licence and download link are still valid. The only difference is the countdown of your VIP support commences on 30 March 2022. Subscriptions and updates are valid for one year. This download link was emailed to you when you purchased Padloper 2. Please contact me if you do not have a download link. Q: I have shops built in Padloper 1 that I'd like to migrate to Padloper 2. I don't have the expertise and/or time to do the migration myself. Is there paid support for this? A: Yes, paid support is available. We can migrate your Padloper 1 shop to Padloper 2 per your specifications. This includes both backend and frontend migration. You can purchase either or both backend and frontend migration. Please contact me to discuss. We will soon add this custom work information to our website. Q: Is there a backend/admin demo of Padloper 2 that I can test pre-purchase? A: Yes. We are currently putting final touches to it. An announcement will be made here once this is ready. Q: Which is now the official Padloper support forum? A: This forum will eventually become the official Padloper support forum Although it is a public forum, we will still be able to offer VIP support. The only difference is downloads will be not be available in the forums, since it is open. Support via email will still be available as well. Q: I am getting a called to undefined function bcmul() after install. What does this mean? A: Please see the minimum requirements for Padloper 2. You will need to install the PHP extension bcmath on your server. This is in order to get accurate rounding off of currencies.
    4 points
  4. I got a lot of questions when reading the above last two posts. A) Why using a php file OUTSIDE of /site/templates ? B) Why using a file that needs to include PWs index.php? C) Why using RELATIVE URLs? (Sounds the worst decision to me) D) Then, why using jQuery? Is it used for other things on the site, or was it coming into play ONLY for the ajax action? A & B) The only reason why to use a external php file, should/would be be to process something OUTSIDE from PW. But when I need PWs internal processing, why leaving it (through the front door) and directly enter it again (through the backdoor)? I would create a template that is called, for example, "ajax", that has the family restrictions: only parent is home cannot have children can be used for ONE page the page can get the URL: /ajax/ The template file, that processes all ajax calls, is called ajax.php then, and is located under /site/templates/ajax.php. Also, when bootstraping PW, you need to declare its namespace at first: <?php namespace ProcessWire; include( PWs index.php ); Without namespace, all following PHP code cannot work properly! <-- HINT! C) The code ./ is the placeholder for the current URL a page lives under. The URL "./../somewhere/", when called on a page like https://example.com/subpage/ points to https://example.com/somewhere/. When I call it on the homepage, it points ABOVE the homepage, what is not possible. When I call it from https://example.com/subpage/subsubpage/ it points to https://example.com/subpage/somewhere/. This looks worse to me. Also, when reading in the code while developing, a URL ./../ doesn't tell me anything about its location, whereas a absolute URL like /site/templates/images/icon.svg does! This delivers more context that can be helpful in many cases. D) @Val_0x42 Do you already use jQuery on your site for other things then ajax? If not, you should use the modern Fetch Web-API that is native available in all modern browsers, what seems to be your target group. (Also, if you want or need to support old browsers like IE11, there are polyfills available for that too 🙂). My suggestion not to use jQuery ajax but the Fetch API is, because you don't know no one of them yet and need to learn one. So, why learning an old thing, that comes with the disadvantage of an additional 150k+ JS lib download, when all the things are already available in the browser engines? Fetch API is future proof! A very detailed fetch request can look like this:
    1 point
  5. Great news! I was busy with other projects so I could not participate on the beta testing but I surely can't wait to give this new version a shot in one of my next projects.
    1 point
  6. Sorry this works, of course it does! Thanks @bernhard. Nothing strange about $sanitizer that I mentioned above...just me. Sorry for wasting your time 🤦‍♂️.
    1 point
  7. This was a bug. Just fixed it now. Thanks.
    1 point
  8. 1. Use the right sanitizer $email = $sanitizer->email($email); $pagename = $sanitizer->pageName($pagename); // OR $pagename = $sanitizer->pageNameUTF8($pagename); 2. Set adjustName to true in the save options array to make your page name unique $np = new Page() // ... $np->save(array('adjustName' => true));
    1 point
  9. Who needs Craft when there is Processwire ?
    0 points
×
×
  • Create New...