teppo

Thanks, Ivan! ? I haven't figured out the details yet, but at some point I'm going to look into adding templating language support. For the time being all options are open, so don't really have anything else to share at this point than "I will look into it eventually". 1. Currently partials are intended as simple drop-in (include) files with very little logic. I do have some ideas in my backlog that come pretty close to this topic, but I'll have to give them a bit more thought before implementing. Wouldn't want to put something in now, and then regret it right away... ? I've often preferred render functions, i.e. functions that generate markup, in case I need to bake some logic into smaller bits and pieces of the site. A "RenderUtils" class with multiple render methods would be one solution, and of course you can already use ProcessWire's own features to render a partial: $page->renderValue(), $files->render(), TemplateFile::render(), etc. In the long term perhaps we could add some kind of a helper class to the framework for handling these situations – just not quite sure yet how to approach this. If you could give me an example or two of what sort of situations you tend to run into, I'd be grateful – would be good to know that I'm actually solving the right problem ? 2. Not Wireframe specifically, but I did build a few rather large sites with pw-mvc and RepeaterMatrix. In those cases I ended up using field templates (/site/templates/fields/) for the bulk of the RepeaterMatrix stuff. Worked quite nicely, really. I'll add a note to write a bit about this to the "Patterns and practices" page.

Hey @Mike Rockett – just wondering if you could add this module to Packagist as well? Would make installing via Composer nice and easy ? Again setting type as pw-module and adding wireframe-framework/processwire-composer-installer as a dependency would be perfect. Thanks in advance for considering!

Hey @Mike Rockett, Any chance you could add this module to Packagist? Would love to use it on my current project, but I'm relying on Composer. Would be nice not to have to install this module via Git or add the repository manually to composer.json. It would also be awesome if you could declare type as pw-module and add wireframe-framework/processwire-composer-installer as a dependency for easy installing. Thanks for considering! ??

Nice! Would be interesting to hear if you can think of anything particularly cool that your version did and Wireframe doesn't do. Always looking for new ideas ? Small update to the docs site: added a page for patterns and practices. Currently only one page there (utility classes), but will be adding more as I figure out what should be there. Doesn't make sense to bundle everything with the module or even the site profiles, so needed some place to stash this sort of stuff.

Agreed. ONLY_FULL_GROUP_BY can be quite tedious to work around, so that's a good candidate for an exception to the general rule. And, just for the reference, it's also one of the modes deemed incompatible with WordPress – so we're not the only ones who've decided that it's not worth it ?

There's no need for a RewriteRule here. The point of these rules is that if they fail (don't match), the request won't be passed to (or "continue to") index.php, which in turn means that ProcessWire won't attempt to serve the file. Instead Apache will try to serve whatever was requested directly from the disk. We'd only need a RewriteRule here if we wanted to divert the request to some other location, or something along those lines ?

$files->send() (WireFileTools::send()) makes use of WireHttp::sendFile(), which in turn reads the file contents using readfile() and outputs it with applicable headers. So no, this wouldn't be affected. Only exception would be the case where you're serving those files from (faked) URLs that match rule 15B – which seems quite unlikely. In that case you'd have to add a -f check here to make sure that a) if it's a real file it won't be downloaded, but b) if it's not the query can be passed to ProcessWire and served from there. But again, I'm guessing that's not a problem for your use case ?

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 ?

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 ?

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!

Hey @Wanze! These aren't really issues, more general feedback, so I thought I'd post them here. I've been evaluating this module as a solution for handling metadata, and as such have finally had some time to actually dig into it's numerous features – and while I see a lot of interesting stuff here, there are a few things that could perhaps use some polishing, in my opinion ? So one thing that confused me initially was the use of word "inherit". I managed to miss the point about default values being set template level in README (which obviously was a major reason for my confusion... but to my defence: when evaluating a new module I like to do it without reading too much first, since that's how most regular users – as in clients – are going to be using it anyway), so I imagined that the values would be inherited from parent pages. (Seemed a bit weird obviously, but whatever.) Now that I've double-checked the docs and understand that those values are inherited from the template, I'm actually wondering if you might consider calling this something else – perhaps "default"? It would also be good to explain somehow (in context) what "inherit" means, and where the value is inherited from? Note: I get that anyone installing the module and having access to template settings should probably realise what this is all about, but I for one don't give clients access to template settings (I see that as the developers' territory). Thus "inherit" doesn't make much sense to them – and since it's not explained in the admin (and they're unlikely to figure out that the site is using SeoMaestro and dig out the modules README or this thread), it can indeed be quite confusing. -- Another source of confusion for me was the Sitemap feature, mainly because it didn't seem to do anything. Now, looking into the source code, I see that you're using file_put_contents() – so apparently the module expects write access to the site root? It might be a good idea to add a check to see if this really is the case. At least I assume that this was the problem – didn't see any errors, but in my case Apache or PHP never have write access to directories with executable code, so if the module did try to write in those directories, it must've failed. (Personally I like the "hook 404 page and serve fake files" approach more when it comes to things like this – it doesn't require write access, and tends to work better overall in different environments.) -- Just some initial observations – hope you don't mind poking around. You're doing great job with this module! ?

In my current job we don't actually use MS Office, and it has never been a real issue. Google's cloud apps are quite good (even better than MS ones in some regards), LibreOffice works for a lot of stuff, etc. The last time I did use MS Office it was actually the cloud based version of O365, due to various issues with desktop MS apps on macOS. My understanding is that this should work for Linux users as well? Anyway, there are two things keeping me firmly in the Mac camp: the UX (which includes both hardware and software), and the app support. Latter has been particularly so for design stuff – Photoshop, Sketch, XD, etc. None of those (to my best knowledge) work on Linux, at least not without some sort of emulator or virtual machine (which imho would pretty much defeat the purpose of running Linux in the first place).

Since this is indeed related to the VersionControl module, I'll merge this thread to the VersionControl support thread ? As the author of said module I should add that VersionControl has not been tested with the ProFields Table Textareas plugin, and honestly I'm not surprised if these two don't play nicely together out of the box. I will take a closer look at this, but it may take a while, so in the meantime I've opened a feature request for this at GitHub: https://github.com/teppokoivula/VersionControl/issues/23. You could take a closer look at the database (particularly the version_control__data table) in case your data is still stored there. Other than that I can't really say for sure – it's possible that the data was not saved correctly, which would mean that it's no longer available. I'm not quite sure what you mean by "having a look at the module itself" ?

Hey @bbeer, There's no such module as "History" (as far as I'm aware), so are you perhaps talking about VersionControl – or something else entirely? Or is this a question about some built-in feature in ProFields Textareas? ? The Modules/Plugins area of the forum is for dedicated module support threads only. If this is a support request for ProFields Textareas, please post the the VIP support area instead – and if it's related to another module, you should post your question directly to the support board of said module. If you're not sure where that might be, check the modules directory entry for the module in question and you'll find a link to the support board from the sidebar (on the left side). If you tell us which module you're talking about, a moderator can move or merge this thread to the right place.

This should work: // char counter: $field->set('showCount', InputfieldText::showCountChars); // or ALTERNATIVELY word counter: $field->set('showCount', InputfieldText::showCountWords);

These were for MarkupMenu, an aria-label within template strings that I wanted to be translatable ? Not sure if I've ever tried this before either; didn't occur to me that it wouldn't be possible, but makes sense now. Anyway, the separate config file idea actually works quite nicely for me in this case. Ready.php would've been a good solution as well ?

For the time being I've resolved this by moving config settings with translatable strings to a separate file, which I'm then including later in the process after ProcessWire has been properly set up. If anyone has a better idea, please let me know ?

I've got a feeling that this is either something that by design shouldn't work, or it's something that has a really simple solution and soon I'll have a major facepalm moment: can we define translatable text in /site/config.php in PW3 – and if so, how? ? So far I'm not having much luck. Calling __('Translatable') produces fatal error, and so does $config->__('Translatable'). (Config extends Wire, so figured latter could've worked.) Based on the errors it seems that this might be an impossible situation: in order to get to the translation functions I'd first have to have a ProcessWire instance running, and I don't have one running before config has been parsed. Any ideas, or am I missing something important here? Here's that fatal error, just for reference: Fatal error: Uncaught Error: Call to a member function wire() on null in /wire/core/Functions.php:25 Stack trace: #0 /wire/core/LanguageFunctions.php(30): ProcessWire\wire('languages') #1 /wire/core/Wire.php(1516): ProcessWire\__('Translatable', Object(ProcessWire\Config)) #2 /site/config.php(90): ProcessWire\Wire->_('Translatable') #3 /wire/core/ProcessWire.php(923): require('/var/www/sites/...') #4 /index.php(33): ProcessWire\ProcessWire::buildConfig('/var/www/sites/...') #5 {main} thrown in /wire/core/Functions.php on line 25

I tend to run all my posts through an online spell checker, just to catch any silly mistakes before they go online. Usually it does a decent job, but sometimes it doesn't quite get the context right. Today's suggestions included – among other more-or-less sensible options – "Wiretap" (for WireHttp), and "Bodybuilder" (for FormBuilder). Then again: since we already have "Admin on Steroids", perhaps a Pro-module called Bodybuilder is just the next logical step? ?

I think that's a brilliant idea, so definitely going to my todo list – thanks for the suggestion! ?

Chaining is based on the idea that your method returns a self-reference, i.e. "return $this", after which you can access another method from the returned object. In your example when you leave $value param of the text() method empty (so that it defaults to "null"), the method returns "$this->text" (which is a string or null) instead of an object – and you cannot use a string (or null) for chaining (it doesn't have any methods). In other words: even if "$this->text" had a non-null value, you still couldn't use it for chaining, 'cause it would return a string and not a self-reference to the containing object ? Based on your code it looks like text() without a $value is supposed to work like a getter, returning the text (string), so technically this is how it's supposed to work. The most obvious option would be defining another method – perhaps something like setText(string $value = null) – that sets the value but always returns $this, and never the value itself. Or you could just modify the text() method so that it cannot be used as a getter for the value, i.e. make that always return $this. Hope this helps a bit ?

For Repeater use (or any complex data type) you'd have to mark an element as a parent and include the child structure within it. And since your items may not all be the same, you'll need if-else. And probably some way to check existence and length of an item as well. ... and just like that you've just invented a brand new templating language ?

Sounds like a bug – if you can reproduce this, please open an issue for it at https://github.com/processwire/processwire-issues/issues ?

Perhaps I'm missing the point, but this should be the easy part. Maybe something along these lines: <?php $current_date = null; $items = $pages->find('template=news-item, sort=date_field, start=0, limit=20'); if ($items->count()) { foreach ($items as $item) { $date = date('j.n.', $item->getUnformatted('date_field')); if ($date !== $current_date) { if ($current_date !== null) echo "</ul>"; echo "<h3>{$date}</h3><ul>"; $current_date = $date; } echo "<li>{$item->title}</li>"; } echo "<ul>"; } It's a bit crude and probably wouldn't work as-is with your infinite scroll approach, but that's the basic idea anyway ?

Right – WSL 2 is indeed an awesome concept. Kind of like having a real Linux box to work with (kidding ?) When it comes to the terminal app, I guess it's just the fact that it's a desperately needed upgrade that makes folks happy. Good for them – and good for me I guess, if I ever have to touch a Windows machine again. Never say never, and so on and so forth ?