Leaderboard

Version 3.0.135 of ProcessWire on the dev branch focuses on adding additional layers of security via .htaccess updates, adds clarity to debug mode, and improves upon the installer— https://processwire.com/blog/posts/pw-3.0.135/

Hey folks! I'm happy to finally introduce a project I've been working on for quite a while now: it's called Wireframe, and it is an output framework for ProcessWire. Note that I'm posting this in the module development area, maily because this project is still in rather early stage. I've built a couple of sites with it myself, and parts of the codebase have been powering some pretty big and complex sites for many years now, but this should still be considered a soft launch ? -- Long story short, Wireframe is a module that provides the "backbone" for building sites (and apps) with ProcessWire using an MVC (or perhaps MVVM... one of those three or four letter acronyms anyway) inspired methodology. You could say that it's an output strategy, but I prefer the term "output framework", since in my mind the word "strategy" means something less tangible. A way of doing things, rather than a tool that actually does things. Wireframe (the module) provides a basic implementation for some familiar MVC concepts, such as Controllers and a View layer – the latter of which consists of layouts, partials, and template-specific views. There's no "model" layer, since in this context ProcessWire is the model. As a module Wireframe is actually quite simple – not even nearly the biggest one I've built – but there's still quite a bit of stuff to "get", so I've put together a demo & documentation site for it at https://wireframe-framework.com/. In addition to the core module, I'm also working on a couple of site profiles based on it. My current idea is actually to keep the module very light-weight, and implement most of the "opinionated" stuff in site profiles and/or companion modules. For an example MarkupMenu (which I released a while ago) was developed as one of those "companion modules" when I needed a menu module to use on the site profiles. Currently there are two public site profiles based on Wireframe: site-wireframe-docs is the demo&docs site mentioned above, just with placeholder content replaced with placeholder content. It's not a particularly complex site, but I believe it's still a pretty nice way to dig into the Wireframe module. site-wireframe-boilerplate is a boilerplate (or starter) site profile based on the docs site. This is still very much a work in progress, but essentially I'm trying to build a flexible yet full-featured starter profile you can just grab and start building upon. There will be a proper build process for resources, it will include most of the basic features one tends to need from site to site, etc. -- Requirements and getting started: Wireframe can be installed just like any ProcessWire module. Just clone or download it to your site/modules/ directory and install. It doesn't, though, do a whole lot of stuff on itself – please check out the documentation site for a step-by-step guide on setting up the directory structure, adding the "bootstrap file", etc. You may find it easier to install one of the site profiles mentioned above, but note that this process involves the use of Composer. In the case of the site profiles you can install ProcessWire as usual and download or clone the site profile directory into your setup, but after that you should run "composer install" to get all the dependencies – including the Wireframe module – in place. Hard requirements for Wireframe are ProcessWire 3.0.112 and PHP 7.1+. The codebase is authored with current PHP versions in mind, and while running it on 7.0 may be possible, anything below that definitely won't work. A feature I added just today to the Wireframe module is that in case ProcessWire has write access to your site/templates/ directory, you can use the module settings screen to create the expected directories automatically. Currently that's all, and the module won't – for an example – create Controllers or layouts for you, so you should check out the site profiles for examples on these. (I'm probably going to include some additional helper features in the near future.) -- This project is loosely based on an earlier project called pw-mvc, i.e. the main concepts (such as Controllers and the View layer) are very similar. That being said, Wireframe is a major upgrade in terms of both functionality and architecture: namespaces and autoloader support are now baked in, the codebase requires PHP 7, Controllers are classes extending \Wireframe\Controller (instead of regular "flat" PHP files), implementation based on a module instead of a collection of drop-in files, etc. While Wireframe is indeed still in a relatively early stage (0.3.0 was launched today, in case version numbers matter) for the most part I'm happy with the way it works, and likely won't change it too drastically anytime soon – so feel free to give it a try, and if you do, please let me know how it went. I will continue building upon this project, and I am also constantly working on various side projects, such as the site profiles and a few unannounced helper modules. I should probably add that while Wireframe is not hard to use, it is more geared towards those interested in "software development" type methodology. With future updates to the module, the site profiles, and the docs I hope to lower the learning curve, but certain level of "developer focus" will remain. Although of course the optimal outcome would be if I could use this project to lure more folks towards that end of the spectrum... ? -- Please let me know what you think – and thanks in advance!

Thank you. Yes, I have purchased ProFields. This is exactly I was looking for. Beautiful and fast!

https://processwire.com/api/ref/pages/get-by-path/

All of these sound like great ideas ? Sure, no worries. I get that there are ups and downs to both approaches. My use case may be a bit unorthodox, but again I never give ProcessWire or the Apache user write access to anywhere that isn't strictly necessary (so only the assets directory, or parts of it). In my opinion giving PHP write access to executable code is asking for trouble. Additionally ProcessWire writing files to the disk can be problematic if you're using automated deployment process – depending on your setup those files may get lost in every deployment, or at least require some extra logic to work properly. Just some points to consider, and of course folks like me can always leave the sitemap feature to another module or custom code. In my opinion the minimum level would be checking if the file can be added, and then somehow warning the user if it can't. Just for reference, here's how I ended up implementing a similar permission check ?

I discovered Wireframe on Sunday after exploring the GitHub repo for the ProcessWire Composer Installer project that you mentioned in the latest PW Weekly. The documentation you've written for Wireframe is just awesome ? - engaging, comprehensive and clear. I have a short question and a long question... Does it make sense to use Wireframe together with Markup Regions in any way, or would a developer choose Wireframe or Markup Regions but not both? The long question relates to what you said here: I take this to be a reference to the superiority of a MVC approach versus the "default" approach of mixing business logic and UI logic together in a PW template file. I'd like to hear more of your views on this because you didn't talk about it much in the documentation, probably because MVC and the separation of concerns is discussed in plenty of other places around the web. But I was wondering if you think a MVC approach is always the way to go, or if is something you would weigh up the pros and cons of taking into account the parameters of each specific project, e.g. the scale and complexity of the project, if a team will be working on the project, etc. Personally I use Markup Regions and don't use any separation of business logic and UI logic into different files or folders. From time to time I think about changing to an MVC approach because so many people seem to recommend it, but when I weigh it up I don't see enough advantage versus disadvantage for the kinds of projects I work on. But maybe I'm overlooking something so I'd appreciate your comments. The main benefits of MVC as I understand it are... 1. If you have a team of people working on a project, maybe with different skill sets (e.g. a front-end dev and a back-end dev), then it lets each person focus on the parts that matter to them. For example the front-end person can focus on the view file without having to see any business logic which might distract or even be unintelligible to them. This totally makes sense to me and if I worked as part of a team this by itself would make an MVC approach worthwhile. But in my case I do everything alone from start to finish - design, front-end, back-end. 2. The business logic doesn't "belong" in the same file as the markup - it's better to keep it separate and it makes it easier to update a site. This seems more contentious to me, and perhaps depends on how much business logic there is. If I have some variable that I'm using within the markup I find it very handy to have the definition/construction of that variable present alongside its usage in output. So I'm not left wondering "what was it that I put into $related_products?" and needing to navigate to some other file to find out. Now if there were heaps of business logic it might start to feel like clutter within the markup, but when I look at the template files for my projects in most cases there's actually very little business logic present. Maybe that's partly because PW is quite elegant in that you can do a lot with a few lines of code, and partly because most of my projects are not very complex. But even if I do have a lot of business logic I find that placing it at the top of the template file is no problem at all. If I need to work on it I'd rather just scroll up than open another file, and I can use my IDE to collapse any blocks of code that I don't need to focus on. Would you say that MVC is an approach that is more suited to complex projects rather than simple ones? Things like layouts and partials that are offered through Wireframe are cool, but those are also possible with Markup Regions (layout = _main.php) and built-in PW methods (partials = $files->render). I have no doubt that Wireframe is a powerful tool, but do you see it as being the right solution for all projects or just some projects?

Hey guys, I found something incredible. Look at this new fieldtype from the CMS Statamic: https://statamic.com/blog/statamic-2.8 It is called Bard and combines the Repeater Matrix with an normal textfield. I think this is a really good way to edit long text. It would be awesome if Processwire could get an similar fieldtype. What do you think? Jannis

I'm almost there... Was a tough ride till this point but I guess it was worth it. Feeling more at home than on Windows or Mac the last few years.

@tonicastillo Many thanks for sending me your images. I have tested with the original image on windows and on linux. My variations always had correct and 100% identical iptc metadata as the original has. (see my screenshot via PM). It seems you have to control which part within your workflow chain is not properly set to UTF-8. If you are using PW >= 3.0.132, you can use the following code to get direct debug output from images and variations: $image = $page->images->first(); // get the original image, (adapt to your needs!) //echo $image->getDebugInfo(); // THIS MUST BE OMMITTED, BECAUSE I FOUND SOME SORT OF "STATIC" BUG WITH THE NEW DEBUG-METHOD $options = ['forceNew' => true]; $variation = $image->width(300, $options); // create / recreate a (new) variation echo $variation->getDebugInfo($options); // debug output Parts you need to check can be the OS default charset and/or codepage, PWs php files, the Webserver DefaultCharset, etc. In the modules directory you can find a useful set of inspection tools: https://modules.processwire.com/modules/process-diagnostics/ that assists in some parts. It has diagnostics for PHP, Webserver, Filesystem, etc. -------------------- PS: Normally it should be possible to query debugInfo for multiple images one after each other, but an optimization error has crept in.

Interesting that Ryan said this when he actually decided to force removal (https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L975) of the new mysql default for "ONLY_FULL_GROUP_BY", rather than properly rewriting the queries to work with the new default.

Did for me. Bluetooth is really dodgy on 10.14.5. Sometimes works with my headphones, sometimes hangs the whole laptop with that stupid spinning beach ball. It's really not acceptable on such a supposedly 'high end' product. But hey, I love this laptop so meh.

Ah, the or groups selector post ? We really needed this a few years ago. Unfortunately Ryan did not manage to implement this. No hard feelings though since this is not an easy task. But I do believe it should be developed since this is a big USP over other rule builders. ProcessWire can really shine with these kind of data structures. I eventually created a Process module which created pages has a sort of multiplier field of InputfieldSelector. The client could scope the main selector and add groups by adding more selectors. - Main Selector template=foo (InputfieldSelector) |-- Selector 1 (OR) somevalue=bar (repeatable field with InputfieldSelector) |-- Selector 2 (OR) someothervalue=foobar (etc) This fields eventually resolved in: "template=foo, (somevalue=bar), (someothervalue=foobar)". I created another Process Module we rendered these selectors in a list and created urls (using the great ProcessPageListerUrls). This might feel like overkill, but the client wanted to query complex selectors.

Hi @tonicastillo, I'm not sure, but it looks like something in your workflow is not utf-8 save. Can you send me one original (uploaded) image, where this happens? You can use PM or my email address, if you like: https://nogajski.de/contact/ Thanks.

Ahh. Your example was fine though; it was my original that wasn't. Who knows. Hate that! Thanks for all the help, you too @bernhard

Definitely go with Repeater Matrix. It's worth every cent. Plus, ProFields has lots of other items you'll find helpful. You'll reduce development time drastically, and your client will enjoy the ease of use and flexibility.

Mentioned in a book For CSS Grid (and also Flexbox): https://cssgrid.cc https://cssgrid.cc/css-grid-guide.html

Thanks @teppo. I'm going to spend some time exploring Wireframe to see how it feels compared to my existing approach - I may yet become a convert ?. Thanks again for creating this tool and doing such a great job on the documentation website.

Hi @teppo Thanks for your valuable feedback! What do you think about calling the label "Inherit default value"? For the explanation, we could use an InputfieldMarkup prior to any meta data fields (similar to the one when editing the default values on field-level). It has been mentioned before that it should be possible for content editors to edit default values without having permission to edit fields or templates. I think the module will (should) include another Process module, which could offer this configuration GUI, along with other interesting things such as SEO reports ? The sitemap does not have to be in the site root necessarily, you could also enter a path to a writeable folder. But you're right, I actually never thought of this problem and also do not check it ? At least this should be mentioned in a description or note. I am aware of the 404 hook, but I do not like it very much, it feels "wrong". Other hooks listening to the 404's might get triggered as well, but then it's no longer a 404 after returning the sitemap. Let me think about this ? Cheers

Hey @Robin S. First of all thanks for your thoughtful message! I'll have to get back to some of your points later, but just wanted to share a few initial thoughts ? About using Markup Regions and Wirerame together: I honestly don't know. I'm aware on a basic level of how Markup Regions work, but I've never used it. I will definitely dig into the specifics, though – this is an interesting area. On a more general note I've intentionally kept to the "alternate template file" strategy (instead of hooking into Page rendering or something similar) so that Wireframe can be used for some parts of the site (some templates), while other parts use whatever other approach makes sense. So yeah, you can use them together, I'm just not yet sure to what extent that would make sense... if that makes sense to you? ? I don't really want to preach the superiority of MVC (or any other three or four letter architecture), but apart from some of the simplest sites I've built – isit.pw has one file with one form, so it for an example doesn't benefit from a whole lot of structure – I do generally prefer to separate "code" from "markup". This is a topic I'd love to cover in more detail later, but your two points summarise very well what it is all about. Project scope (and complexity) and working with or without a team are definitely key factors there. After that it comes down to personal preference. TL;DR: I wouldn't use Wireframe for everything, but I do think that it fits nicely just about any project. I often end up with multiple "views" for the same data – not sure if this is really a common need, but it has been in my projects, which is another reason to keep the views as basic (and as markup-y) as possible, and instead move all the business logic, data structuring, etc. somewhere else. Overall I've found that this sort of structure helps me keep things neat so that when things eventually grow and scale it doesn't become a mess, and allows me to make changes and additions with little extra overhead once they are due. That being said, there's a good reason why Controllers – for an example – are actually optional components in Wireframe. Some of my templates make use of the whole package – Controller, layout, view file(s), and partials – yet others have just a single view file, and that's all. I like that I don't have to use more than I really need, but if I do need more later, I can just bolt it in without a whole lot of refactoring ? It's true that you can use ProcessWire's built-in features to do everything that Wireframe does. That's exactly what Wireframe itself does: I've tried not to reinvent the wheel where possible, so the View (for an example) is a light-weight wrapper for TemplateFile, etc. Originally the predecessor of this project (pw-mvc) was all about standardising some best practices so that as we (as a team) build a project after project there's some common ground there. In a perfect world you could jump into a new project you've never touched before and instantly see what's going on in there. It's a bit more than that now, though. ... and this is the point where I realise that my "few initial thoughts" are already getting quite long-winded ?

@Torsten Baldes, there has been an @todo note about adding OR-group support to InputfieldSelector since 2016. Seeing as Ryan has been doing some work on InputfieldSelector recently it might be timely to open a request for this in the requests repo to bring it back to his attention. ?

@jonassalen, open the ProcessSetupPageName.module file in your code editor and try replacing this section at the top of the createFromFormat() method... if ($languageID == null && $this->languageSupport == true) $languageID = $this->wire('languages')->getDefault()->id; $langID = $this->wire('languages')->get($languageID)->isDefault()? null : $languageID; if ($this->languageSupport) { $userLang = $this->wire('user')->language; $this->wire('user')->language = $this->wire('languages')->get($languageID); } ...with... $langID = null; if ($this->languageSupport) { if ($languageID == null) $languageID = $this->wire('languages')->getDefault()->id; $langID = $this->wire('languages')->get($languageID)->isDefault()? null : $languageID; $userLang = $this->wire('user')->language; $this->wire('user')->language = $this->wire('languages')->get($languageID); }

SeoMaestro (including myself) knows nothing about TemplateLatteReplace, so I cannot influence settings of this module. I am not sure why the LatteReplace would try to render the structured data template, I assume it's because SeoMaestro internally uses a ProcessWire TemplateFile to render the markup: https://github.com/wanze/SeoMaestro/blob/master/src/StructuredData/BreadcrumbStructuredData.php#L52-L55 There is nothing I can do from Seo Maestro's side about this, and I assume you will have problems with other modules as well that are using ProcessWire's TemplateFile for rendering. My TemplateEngineFactory module providing template engines like Twig, Smarty, Pug etc. does not suffer from this problem, because it hooks after Pager::render rather than TemplateFile::render. Cheers

Also worth noting: https://stackoverflow.com/questions/5943149/rebase-array-keys-after-unsetting-elements

@stanoliver Great ? Array elements that are declared without a key are implicitly numeric in PHP, so the following declarations are equivalent: $colors = [ 'red', 'green', 'blue', ]; $colors = [ 0 => 'red', 1 => 'green', 2 => 'blue', ]; You can even mix numerical and associative arrays, but that only leads to confusion in my opinion, so I would avoid it.

The line in question is: $isTranslatable = $info['translatable'] ?? false; The "Null coalescing" operator was introduced with PHP 7 - are you sure you're using PHP 7.2? ?

Hi @Juergen This should work: $page->seo->robots->noIndex = 1; $page->seo->robots->noFollow = 1; Cheers

Or use the option manager with a fixed string, something like this: $field->save(); // save field first $manager = new \ProcessWire\SelectableOptionManager(); $manager->setOptionsString($field, __("Yes\nNo"), true); $field->save();

The CSS Grid vs Bootstrap (or any other CSS framework/library) question does not make too much sense anyway Just because now we have CSS Grid it does not mean that it provides all the stuff a heavy weight CSS framework gives us. We are comparing apples to oranges... CSS Grid solves one particular – albeit long standing – issue, that's all there is to it.

Thanks - I understand that when using "language alternate fields" it automatically used the field based on the language name in the "_suffix" but are you saying it also works if I had two pdfs in the one files field named: "mypdfname.pdf and "mypdfname_portugues.pdf" - so if the user has selected the default English they will get the first one and if they select the dutch language the second one will be automatically linked to instead? I just did some basic testing and I don't see it functioning that way. What does work (and what I assumed I would have to do if I upload all language versions to the one files field), is this: $page->document_pdf->get("name*=portugues")->url obviously replacing "portugues" with the current language. Am I missing some other way to do this? I am actually thinking that separate language alternate fields will probably be easier for the site editors, but I am still curious to know if there is a different approach I am missing.