Leaderboard

A new module that hasn't had a lot of testing yet. Please do your own testing before deploying on any production website. Custom Paths Allows any page to have a custom path/URL. Note: Custom Paths is incompatible with the core LanguageSupportPageNames module. I have no experience working with LanguageSupportPageNames or multi-language sites in general so I'm not in a position to work out if a fix is possible. If anyone with multi-language experience can contribute a fix it would be much appreciated! Screenshot Usage The module creates a field named custom_path on install. Add the custom_path field to the template of any page you want to set a custom path for. Whatever path is entered into this field determines the path and URL of the page ($page->path and $page->url). Page numbers and URL segments are supported if these are enabled for the template, and previous custom paths are managed by PagePathHistory if that module is installed. The custom_path field appears on the Settings tab in Page Edit by default but there is an option in the module configuration to disable this if you want to position the field among the other template fields. If the custom_path field is populated for a page it should be a path that is relative to the site root and that starts with a forward slash. The module prevents the same custom path being set for more than one page. The custom_path value takes precedence over any ProcessWire path. You can even override the Home page by setting a custom path of "/" for a page. It is highly recommended to set access controls on the custom_path field so that only privileged roles can edit it: superuser-only is recommended. It is up to the user to set and maintain suitable custom paths for any pages where the module is in use. Make sure your custom paths are compatible with ProcessWire's $config and .htaccess settings, and if you are basing the custom path on the names of parent pages you will probably want to have a strategy for updating custom paths if parent pages are renamed or moved. Example hooks to Pages::saveReady You might want to use a Pages::saveReady hook to automatically set the custom path for some pages. Below are a couple of examples. 1. In this example the start of the custom path is fixed but the end of the path will update dynamically according to the name of the page: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'my_template') { $page->custom_path = "/some-custom/path-segments/$page->name/"; } }); 2. The Custom Paths module adds a new Page::realPath method/property that can be used to get the "real" ProcessWire path to a page that might have a custom path set. In this example the custom path for news items is derived from the real ProcessWire path but a parent named "news-items" is removed: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'news_item') { $page->custom_path = str_replace('/news-items/', '/', $page->realPath); } }); Caveats The custom paths will be used automatically for links created in CKEditor fields, but if you have the "link abstraction" option enabled for CKEditor fields (Details > Markup/HTML (Content Type) > HTML Options) then you will see notices from MarkupQA warning you that it is unable to resolve the links. Installation Install the Custom Paths module. Uninstallation The custom_path field is not automatically deleted when the module is uninstalled. You can delete it manually if the field is no longer needed. https://github.com/Toutouwai/CustomPaths https://modules.processwire.com/modules/custom-paths/

Since it's featured in ProcessWire Weekly #310, now is the time to make it official: Here is Twack! I really like the following introduction from ProcessWire Weekly, so I hope it is ok if I use it here, too. Look at the project's README for more details! Twack is a new — or rather newish — third party module for ProcessWire that provides support for reusable components in an Angular-inspired way. Twack is implemented as an installable module, and a collection of helper and base classes. Key concepts introduced by this module are: Components, which have separate views and controllers. Views are simple PHP files that handle the output for the component, whereas controllers extend the TwackComponent base class and provide additional data handling capabilities. Services, which are singletons that provide a shared service where components can request data. The README for Twack uses a NewsService, which returns data related to news items, as an example of a service. Twack components are designed for reusability and encapsulating a set of features for easy maintainability, can handle hierarchical or recursive use (child components), and are simple to integrate with an existing site — even when said site wasn't originally developed with Twack. A very basic Twack component view could look something like this: <?php namespace ProcessWire; ?> <h1>Hello World!</h1> And here's how you could render it via the API: <?php namespace Processwire; $twack = $modules->get('Twack'); $hello = $twack->getNewComponent('HelloWorld'); ?> <html> <head> <title>Hello World</title> </head> <body> <?= $hello->render() ?> </body> </html> Now, just to add a bit more context, here's a simple component controller: <?php namespace ProcessWire; class HelloWorld extends TwackComponent { public function __construct($args) { parent::__construct($args); $this->title = 'Hello World!'; if(isset($args['title'])) { $this->title = $args['title']; } } } As you can see, there's not a whole lot new stuff to learn here if you'd like to give Twack a try in one of your projects. The Twack README provides a really informative and easy to follow introduction to all the key concepts (as well as some additional examples) so be sure to check that out before getting started. Twack is in development for several years and I use it for every new project I build. Also integrated is an easy to handle workflow to make outputs as JSON, so it can be used to build responses for a REST-api as well. I will work that out in one section in the readme as well. If you want to see the module in an actual project, I have published the code of www.musical-fabrik.de in a repository. It runs completely with Twack and has an app-endpoint with ajax-output as well. I really look forward to hear, what you think of Twack?! Features Installation Usage Quickstart: Creating a component Naming conventions & component variants Component Parameters directory page parameters viewname Asset handling Services Named components Global components Ajax-Output Configuration Versioning License Changelog

This post covers a few of the bigger updates in ProcessWire 3.0.154 and 3.0.155 on the dev branch. This includes a new function for live replacement of text in core and modules, a new method for creating canonical URLs, and some major upgrades to our $input->urlSegment() method that I think you’ll like! This continues from last week’s post in the ProcessWire support forum about 3.0.154 core updates and includes several new details— https://processwire.com/blog/posts/pw-3.0.155/

@jonatan I appreciate your excitement. As I may have mentioned before, the biggest feature of this module is around making a good page building experience for non-technical people and making it easy to setup as a developer. "Page builders" in my opinion lie on a spectrum: On the right end you have things like Webflow which is 100% visual and infinitely flexible (let's put aside the fact that it's also a CMS and remotely hosted). It's an amazing tool, even though I don't use it because it's not how I develop. It's a great system, but requires design skill and you have to make sure you are consistent across the board, stick to a style guide, etc. On the left end you have what I will call section builders. Perfect examples include RepeaterMatrix and ACF Flexible Content field for WordPress. I made a video comparing the two in my WP vs. PW series. This approach was probably the go-to approach from... 2010 to 2015? It's much less "flexible" in that at it's simplest form, a section like "image left, text right" will always be as such and unless there are other sections to choose from, you are stuck with it. In the middle-right you have things like Gutenberg, Elementor, Brizy, etc. This is where most of the development action is, thanks to reactive JS frameworks (same with Webflow). In the middle-left there are tools like N1ED, Froala Blocks and others. The way I see it, ProcessWire is a tool geared for developers, and developers can customize it perfectly for their clients. A big part of this is a good page building experience and (a) after having built dozens of websites with RepeaterMatrix and (b) experimenting with different approaches and (c) trying to respect ProcessWire's way of doing things, I have concluded that the section builder / repeater matrix approach is the way to go. It just needs to be improved a bit. (also, I'm lazy and would never be able to program a visual page builder like the fancy ones out there because my JS skills are embarrassing) First, why do I say it's the way to go? Because it's regular ProcessWire, you can do multi-lingual, while not a big deal for me, PW seems to be a favorite for multi-lingual websites. So that's important. Because they are normal template files, a matrix-type that has been used multiple times can easily be modified by editing the template file (requires the developer obviously). Because it's regular ProcessWire, you can SWITCH from one matrix-type to another and retain your data. This is pretty important. Because they are normal template files, you can technically load them directly on other pages that don't even utilize repeater matrix and just inject your own content. YOU CAN DO DYNAMIC CONTENT!!! Well other page builders are doing this more and more, but with ProcessWire, you can do it much better (I'll elaborate on this another day and how my module will do it). I just don't trust non-technical people to create a good looking page from a bunch of sections by dragging and dropping and having too much flexibility. Fonts being mis-matched, colors all over the place, responsive thrown off. This is why I don't like page builders like Gutenberg, Elementor and the like. They look very sexy in the beginning and might be OK for people with web page creation experience, but it gives too much flexibility and web pages are complicated when you consider responsive design, image sizes, etc. I can use my CSS framework of choice (UIkit of course) instead of whatever internal CSS framework each of those builders relies on. So, what problems do section builders currently have (like RepeaterMatrix)? You cannot "preview" a section in a slick way before you add it. Sure, the matrix-type might be named "text left, image right" among a sea of 20+ other matrix types, but this won't stand out, especially in that smashed together list of matrix-types that you get with RepeaterMatrix. Non-technical people are VISUAL, so getting a preview of what they are about to insert goes a long way. My module has solved that problem as I posted in that above video (it's changed a bit from that video in a much better way). You don't page the benefit of instant feedback of what a section (and overall page) looks like as you populate the content. Again, this goes back to the visual nature of people and the soaring popularity of page builders like the ones I mentioned. Given ProcessWire's strict separation between frontend and backend this also gets complicated because ProcessWire's philosophy is about keeping the two separate. However, the true way around this is to use something like ProDraft's Live Preview feature. At this moment in time, it doesn't autosave + live preview changes to repeater/repeatermatrix items, but I've asked Ryan if he could add this (post is here; not viewable if you haven't purchased ProDrafts). He said it's possible and hopefully one day it will be there. When it does get developed, this in my opinion solves the visual feedback aspect of section builders. As a developer, it's annoying to have to continually re-setup repeater matrix for every site. It's not easy to share the template files across various sites which would be ideal. Also, you have to code your own matrix templates and add all the fields accordingly. As a content editor, you want flexibility in the types of layouts... what if you want your "text left, image right" instead of "image right, text left"? Because you can't physically drag-and-drop those elements, then we are forced in having more section templates that address the most common cases. Therefore my module solves this problem by providing 200+ section templates out of the box (and growing). It also provides an alternative (more visual) interface by which you can register those templates into the repeatermatrix section builder fields all from the admin (none are registered in a fresh installation... you choose what you want, so this avoid bloat). And it feels very to the ProcessWire admin interface (a pet-peeve of mine are plugins in WordPress that have their own garrish, bloaty graphics... example: https://wordpress.org/plugins/wordpress-seo/). The important point here is this: content editors / non-technical people / whatever you want to call them therefore no longer have to worry about dragging-and-dropping layouts, potentially messing things up. My belief is if you provide them with a good set of options, they will find what they need, choose the matrix type and then just focus on the content. ProcessWire's backend is all about having a good content entry experience and the ideas I've played around with have evolved around that concept. We want non-technical people to focus on their content and we as developers should not have to worry if they uploaded a 20mb image, because the matrix template will take care of that. Give me a couple weeks and I'll make a video.

Release date: 7 October 2016 https://processwire.com/blog/posts/processwire-3.0.36-and-looking-forward/ This warning started in PHP 7.2, release date: 30 November 2017 https://en.wikipedia.org/wiki/PHP#Release_history PHP is adding and deprecating features all the time. Not just a ProcessWire thing, but in general you don't want to run PHP software on a PHP version that didn't exist when that software was released.

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

DEPRECATED If you are interested in the new version (commercial module launching in 2023) write me a PM --- Some of you might have followed the development of this module here: https://processwire.com/talk/topic/15524-previewdiscussion-rockdatatables/ . It is the successor of "RockDataTables" and requires RockFinder to get the data for the grid easily and efficiently. It uses the open source part of agGrid for grid rendering. WHY? ProcessWire is awesome for creating all kinds of custom backend applications, but where it is not so awesome in my opinion is when it comes to listing this data. Of course we have the built in page lister and we have ListerPro, but none of that solutions is capable of properly displaying large amounts of data, for example lists of revenues, aggregations, quick and easy sorts by the user, instant filter and those kind of features. RockGrid to the rescue ? Features/Highlights: 100k+ rows Instant (client side) filter, search, sort (different sort based on data type, eg "lower/greater than" for numbers, "contains" for strings) extendable via plugins (available plugins at the moment: fullscreen, csv export, reload, batch-processing of data, column sum/statistics, row selection) all the agGrid features (cell renderers, cell styling, pagination, column grouping etc) vanilla javascript, backend and frontend support (though not all plugins are working on the frontend yet and I don't plan to support it as long as I don't need it myself) Limitations: While there is an option to retrieve data via AJAX the actual processing of the grid (displaying, filtering, sorting) is done on the client side, meaning that you can get into troubles when handling really large datasets of several thousands of rows. agGrid should be one of the most performant grid options in the world (see the official example page with a 100k row example) and does a lot to prevent problems (such as virtual row rendering), but you should always have this limitation in mind as this is a major difference to the available lister options that do not have this limitation. Currently it only supports AdminThemeUikit and I don't plan to support any other admin theme. Download: https://gitlab.com/baumrock/FieldtypeRockGrid Installation: https://gitlab.com/baumrock/RockGrid/wikis/Installation Quikckstart: https://gitlab.com/baumrock/RockGrid/wikis/quickstart Further instructions: https://gitlab.com/baumrock/RockGrid/wikis/quickstart#further-instructions German Translation File: site--modules--fieldtyperockgrid--fieldtyperockgrid-module-php.json Changelog: https://gitlab.com/baumrock/FieldtypeRockGrid/raw/master/changelog.md Module status: alpha, License: MIT Note that every installation and uninstallation sends an anonymous google analytics event to my google analytics account. If you don't want that feel free to remove the appropriate lines of code before installation/uninstallation. Contribute: You can contribute to the development of this and other modules or just say thank you by testing, reporting issues and making PRs at gitlab liking this post buying me a drink: paypal.me/baumrock/5 liking my facebook page: facebook.com/baumrock hiring me for pw work: baumrock.com Support: Please note that this module might not be as easy and plug&play as many other modules. It needs a good understanding of agGrid (and JavaScript in general) and it likely needs some looks into the code to get all the options. Please understand that I can not provide free support for every request here in the forum. I try to answer all questions that might also help others or that might improve the module but for individual requests I offer paid support (please contact me via PM). Use Cases / Examples: Colored grid cells, Icons, Links etc. The Grid also has a "batcher" feature built in that helps communicating with the server via AJAX and managing resource intensive tasks in batches: Filters, PW panel links and instant reload on panel close: You can combine the grid with a chart library like I did with the (outdated) RockDataTables module:

Stripping off empty paragraphs can be harder than it may sound: As requested by @netcarver I put it into a textformatter module: https://github.com/BernhardBaumrock/TextformatterRemoveEmptyParagraphs https://modules.processwire.com/modules/textformatter-remove-empty-paragraphs/ TextformatterRemoveEmptyParagraphs ProcessWire Textformatter to remove empty paragraphs from CKE fields Removes empty paragraphs from a html string. A paragraph is considered to be empty if it only contains one or more of the following: regular whitespace UTF-8 encoded whitespace all variants of <br/> PS: I'm actually not sure if that makes sense as Textformatter at all. IMHO this should be done on processInput, so it's more a sanitization than a textformatter... @netcarver what do you think, as you requested this... ?

There is a textformatter for this here: https://modules.processwire.com/modules/textformatter-srcset/ It’s somewhat old, but probably works fine.

You need double quotes. If you had debug on, this would have thrown an exception: Change it to this: $items = $pages->find("template=items-ordered,supplier={$page->parent->title}");

Thanks for the update. This implementation is a bit weird to me: // Get previous URL segment $prev = $input->urlSegment('=bar'); Perhaps a new urlSegmentBefore() (and after) or a second parameter would be more readable.

Hi @horst, On top of my head: Add the Croppable image field. (plain install, no update) Configure the field & attach to user template. Allow the field in ProcessProfile. (You should configure it in ProcessProfile) Go to your ProcessProfile and click the thumbnail button you configured. As you can see in the browser input bar when ProcessProfile is open there is no get parameters present in the URL. p.s. I'm open for a telephone call :-).... send you a PM with my mobile number.

Thanks @bernhard, didn't know about ProcessEmailToPage. Yup, extensions are pretty easy I've made a few for personal use, eg one for emulating a user scrolling a page to capture consistent videos of page scrolls. What you suggest is exactly what I thought, could distribute builds to each user with a unique token.

Wow @Jonathan Lahijani, just wow! ? That's what I call an elaborative answer! ?? I think your analysis is simply just so great! I almost couldn't agree more upon what you're saying! Your spectrumfication of page builders as well as your pros and current-issues overview of the "leftwing" section builders approach is really great! – YES! I personally adore Webflow! I actually came from the Webflow community a while before joining PW. I'm also myself much more of a visual designer ? than I'm actually a developer ?. And also.. Wf is pricy, PW is free & open source! ? I've mostly taught myself HTML & CSS and copy pasting JS back in primary school, which is enough for Webflow, and then since recently joining PW also basic PHP ("necessity is the mother of invention"). Webflow is truly an amazing tool I agree, but as you mention, on the other hand it does require more design skills (though I believe, not having updated myself on Wf that much recently though, that they're constantly improving their CMS experience and templating experience...) HEAR, HEAR!!! AGREE!!! ?? This is what I meant with : – It's great to let the editors gain some creative freedom, but on the other hand, if they're not designwise nor technically skilled, whichever beautiful design you've created, you'll see them make it fu***** ugly!... Before PW, before Wf, I was using the very basic (though it had CSS and HTML editing...) site builder Weebly. This problem you describe would exactly be the case. Because whatever you'd have designed, the editor (not being neither designer nor technically skilled) would simply (with good intentions though) make it ugly! Because they are simply given too much freedom, more than what's good. Then talking about the kind of slightly (only just slightly) more sophisticated solutions , you have Elementor, as you also mention. Recently I built a site in Elementor. And what a pain!.... Building slightly more advanced templates and custom functionality and design features directly in the Elementor editor is way much more "hacking" and so so so much "fixing" (in general applies to all of WP) more than it's actually developing or designing. The idea is good. The reality is.. not so good. Talking about this... Would the amazing module that you're building also be interchangeable in regards to CSS framework wise, say able to – easily – use Bootstrap instead of UIkit? Perhaps even somehow built in? All in all though I just can't wait to see this! I'm very much looking forward for your video. And again, any kind of sneak peeks or even some beta demo would be highly highly appreciated! All the best, Jonatan

Have a look at this post:

Yes, in general all autoloaders work this way. Composer just generates a file that registers an autoloader function through spl_autoload_register. This function is then called whenever a class is used that is not loaded yet, as a last chance to load the class before an error is thrown. Composer has a few different ways of locating the class files though. You can even generate an optimized autoloader that includes a class map which will speed up autoloading a bit. You can also test if a class is loaded already or autoloaded with class_exists: // using class_exists with false as the second argument, the autoloader will not be called // this return false for all classes that have not been manually included or autoloaded yet var_dump(class_exists('Some\Vendor\Class', false)); // this will trigger the autoloader, so even if the previous call returned false this will return true if the class exists var_dump(class_exists('Some\Vendor\Class')); I have a bit more information on Composer usage in my Composer for ProcessWire tutorial ? Personal preference! I do believe that the .module files themselves need to be inside the ProcessWire namespace in order for ProcessWire to correctly load them in all situations. But ProcessWire doesn't know about the files in the src directory, so I could use any namespace I wanted (for Composer libraries, you'd usually use the developer / organization name as the top-level namespace, so I might have used something like MoritzLost\TrelloWire). It just felt wrong to me to have the main module files inside the ProcessWire namespace and the API in an entirely different namespace, this is why I used ProcessWire\TrelloWire.

Sup. FieldtypeOpenWeatherMap [GitHub] This module fetches and stores current weather data from the OpenWeatherMap.org service and helps you manage icon markup. To limit requests, OpenWeatherMap.org’s JSON-response is cached in the database and only refreshed once the field is accessed and the cache has a certain age that you define. The fieldtype is sadly not multilingual, but you can configure the language of the weather descriptions OpenWeatherMap.org provides you with. It would not be hard to make the output multilingual by referencing weather codes and translating them with ProcessWire’s built in tools. You install FieldtypeOpenWeatherMap just like any other module, by placing the two files into ProcessWire’s modules directory. Once installed, you want to create a new field of the type OpenWeatherMap and assign it to a template. The template now has a text field that stores a city id. In the field settings, you may configure how and when the data is requested. That is, the requested language, units (eg. °C/°F/K) and the cache duration. The module does not provide you with built in icons or otherwise limits you to predefined markup (which I consider a good thing ). The icon in my example above is courtesy of Alessio Atzeni’s Meteocons (custom free license). To make generating icon markup a little easier, you can configure your own markup snippets in the module configuration: As you can see, in this example I’m using an icon font whose appearance is defined elsewhere in my CSS, but you’re free to put in image urls or just unicode entities or whatever. Rendering it is now quite simple. The following markup would result in something like the image above: <?php $w = $city->weather; $temp = round($w->temperature); ?> <p><?php echo "{$w->renderIcon()} {$w->description} at {$temp} °C"; ?></p> <h2><?php echo $city->title; ?> <span class="ico-rightarrow"></span></h2> <!-- irrelevant line --> The variable $w is now a WeatherData object that exposes the following properties: json //The raw JSON response from OWM timestamp //The time of the request city_id //The city id you entered in the admin sunrise //The time of sunrise sunset //The time of sunset main //The main weather name, e. g. “Rain”, in the configured language description //A slightly longer, more precise description like “occasional rain” iconcode //The internal icon code for this weather temperature //The temperature in the format you requested min_temperature //... max_temperature //… wind_speed //I believe the wind speed is also affected by the unit settings. As well as the method renderIcon(), which you already know. If you access a WeatherData object as a string, you will get the city id. This is so that the city id will correctly appear in the admin page edit form. I should mention that there is some more information in the JSON, such as wind direction. The module also exposes the method multiRequest(PageArray $pages, $fieldname). If you want to fetch data for a bunch of pages at the same time, you may want to use that so as to reduce unnecessary requests to the service. I haven’t really used this yet, so consider it experimental, I guess. As of now, this also disregards the cache freshness. If you’re still reading, there’s a chance you might be interested in using this. Allow me to clarify that right now there is no support for forecasts or historical data (yet?). Sorry :> Here’s the GitHub link: FieldtypeOpenWeatherMap.

Not sure if that would help, but I'm curious: Have you ever tried RockFinder2 ? ? +1 for custom db tables and custom SQL. RockFinder2 makes combining custom SQL + PW magic (like access control, hidden/published pages, pagination etc) really easy!

If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree. If I understand you both correctly this is what I'm doing with RockFinder2 + RockGrid / RockTabulator. It's far from perfect yet, but it's built for managing content in a non-hierarchical way which is a very common need IMHO. I don't like listers for that purpose at all. They are limited, they are ugly (*personal opinion!* taking too much space etc), they are hard to customize (like colorizations etc), they are not reacting fast to user input. Of course, there are good reasons why they work as they work: Scalability, access control, multilanguage. These are all points that are challenges for my modules. But in all my projects the benefits of having structured grids of data that are nicely designed, compact and "reactive" (like when filtering columns etc.) outweigh the cons. Not saying my modules are the way to go or better than what you describe. Just wanted to share what is already there and how I'm using it.

My module is going through quite a bit of evolution, almost on a daily basis, as I build more sites with it. It will probably be ready sometime this summer, including documentation and a website. It's quite complex, but very thorough. I've built about 10 sites with it so far, with each site providing various insights and feature ideas that make it into the module.

I guess that tool was not exactly built for mocking up a ProcessWire template/field-setup ? But I think this could be quite helpful - also for asking/explaining questions here on the forum! https://dbdiagram.io/

Greetings, I think you hit right at the point here. If people come to ProcessWire seeking a plugin-dependent, template-based system, they will have problems with it. (Of course, it's also not quite right to compare ProcessWire to Laravel, but that's at least a closer comparison). Over the past few years, I've treated ProcessWire like a Framework that includes built-in admin enhancements. My clients actually really like the default admin interface for most of their sites -- including those who came from WP. Now, comparing ProcessWire to SquareSpace (or any of the other "site builders") is ridiculous, and anyone who makes that comparison is revealing their ignorance. With all that, I'll still say what I've said for years: ProcessWire should be openly discussed as a hybrid framework/CMS. That way would reduce misunderstandings like that of this reviewer. Matthew

Another thing I love about PW is the friendly, supportive forum. I certainly don't want to be accused of trolling the guy. He put his opinion out there based on his experiences, as is his right. Should he venture here though, I'd be more than happy to help him with his PW site

"You can't fix 'stupid'" is an old saying. Sure PW is not for everyone and as the guy said, "Great for developers (I assume), pretty bad for everyone else". What got up my nose was he presents himself as a web developer/designer/guru and his own site is technically bad. Done well, PW is great for everyone. I suspect where he got lost was "assuming" that PW was a load the app, apply a FE theme, bung in a few plugins, squeeze your content to fit the theme and away you go. The thing I love most about PW is the exact opposite. I have complete freedom to build my sites, backend, frontend & user-friendliness

I don't agree ? If a reviewer has no useful knowledge of a system he is reviewing (he states: "I assume"), then he should not do the review in the first place, so "You can't fix 'stupid'" is a proper way to put it in a few words, even though it is a bit offensive, sure, but he deserves it in this case, and we are writing in the Pub section... I'd also like to point out that such a statement by the reviewer is dumb. He might also say that "Laravel is great for developers (I assume), pretty bad for everyone else.", for example. Reading his complete review, he clearly has no idea what he is talking about. PW's admin – by default – is for developers, so why comparing it to WP's and Squarespace's admin, which are for bloggers and such by default? Apples to oranges? I am also a person who did not want to spend the time on exploring ProcessWire for the first time I installed it. At that time I was jumping on the WP bandwagon and thought: so many options to explore, I have no time to explore a yet another system. Later on, I realized what a piece of you-know-what WP's internals are, so I gave ProcessWire another chance, never regretting it, of course?

I don't think it's fair to blame him for his opinion. I think there are some valid points in it. He clearly has a non-tech marketing background and I can imagine that some kind of problems get a huge challenge with ProcessWire that are simply some clicks on other platforms. We know the pro's and con's, but if you don't have the technical background I can really understand that you get frustrated with ProcessWire. Not everybody has the time or will to learn things "from scratch". The headline states that he assumes PW is great for developers, pretty bad for everyone else. While I don't agree 100% on that, the point that PW aims on developers is true. I'd maybe add that it is also great for clients. But that's not always the case, to be honest: I think we all have had situations where we've stored data (settings, lists of countries and so on) somewhere in the page tree, because that's the way to do it in PW... But that's not the way someone coming from other platforms would assume it to be. I guess they'd be looking for it somewhere in the menu, in some listings or whatsoever... I've also needed @gebeer convincing me that it is a great platform. But I enjoy all the technical challenges, so that'll most likely be a totally different experience than someone who he calls "business users" might have ?

After looking at his site, my guess is "You can't fix 'stupid'"

If we check the reviewer website (https://dougmcarthur.net/) then we understand why he sees the Processwire environment so difficult and complicated, even for Wordpress standards this website is very simple: a theme template and a couple of posts. Additionally for that plain homepage in the "recommended" Wordpress it needs: Fully Loaded Time: 9.4s Total Page Size: 5.68MB Requests: 52

Sounds great. The less opinionated, the better ? To answer your original question: SPA profile (Vue, React, Angular or whatever is "cool" this season) Headless profile (perhaps using GraphQL or a simple REST for the frontend to quickly grab content and assemble whatever you wish) PWA profile (service workers, Cache API, a frontend setup showing how you can build pages that can be used even when offline - "app shell" philosophy) "pure awesomeness" starter profile that has the coolest modules already pre-installed, like Tracy, BCE, AOS etc. (the actual choice is of course highly debatable). This would - in a nutshell - show the combined power of what's in the core already - and then some.

I'm having a problem with the $page API. I'm working on some custom admin actions / links for the frontend, and I want to check permissions before I display some links. Specifically, I'm trying to display a trash link if the page is trashable by the current user. I've tried both $page->trashable and $page->deleteable. Unfortunately, both of those seem to always return false when the page I'm calling this on is the page being viewed (i.e. I'm using the literal $page variable in my template). Is this by design? Some sort of prevention against trashing the page that is currently being viewed? I can't seem to find the method in the source code, so I'm not sure how to look it up. The documentation only says: Nothing about a special case for the current page ... Anyway, how can I reliably if a page is trashable? Do I need to take a detour through the template settings? Thanks!

@dragan This happens even when I'm logged in as the superuser, so it should bypass any permission checks. The permissions are definitely right, it only occurs for the current page. For example, I have a news listing being generated by a loop, and $news->trashable correctly returns true inside the loop. But when I view an individual news page, $page->trashable returns false for that very news ... I'm using the latest Dev-Branch (3.0.130) by the way, maybe this is a bug that was introduced recently?

Exactly. It's just a bit custom CSS. ? It might also be an idea for a matrix update that you can configure labels as images. Would be more flexible.

A couple of months ago we launched our very first PW site, which was just a very small site concerning a conference taking place in 2020. Last week we launched our second site, and it was a much bigger project - https://jobs.antarctica.gov.au/. Our jobs (both in Antarctica and within Australia) were previously a part of our main site at http://www.antarctica.gov.au (which is yet to be redesigned and moved into PW), so we were tasked with creating a brand new site in time for the recruitment season opening in early December. While the timeframe was tight (we only had about a month to build it), it was great to be able to work within PW, and then to introduce our editors to it. They love it in comparison to our old CMS (as do we!).

It's great to see a government agency using Processwire. Here across the Tasman, I think Silverstripe has been mandated as the government CMS of choice which is sort of ok in some respects, but it's a lot more complex than it needs to be for many projects.

ok is the installation in a subfolder ? e.g. www.yourdomain.com/ <- index.php // index of pw or www.yourdoimain.com/subfolder/index.php //subfolder is the name of your folder Than you have to change to # RewriteBase / RewriteBase /subolder/ # RewriteBase /~user/