teppo

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 ?

Serious question: were tabs, colors, and splittable windows the kicker here, or did I miss something important? That sounds... well, pretty basic, to be honest. No OS shaming intent here, just not sure if I've understood what this is all about. And, for the record, I'm a huge fan of VSCode – Microsoft has been building some really awesome products in recent years ?

That can definitely be a bit of a pain, and applies to any migration really ? The good thing about the way WordPress handles internal links is that they are all (assuming they've not been modified via hooks or plugins, and a plugin hasn't been producing loads of "non-standard" links) absolute URLs with predefined prefix for each custom post type, and as such – in a lot of cases – you can just run a string replace on the exported data. If you're working on a copy of the site, you can also use WP-CLI (if you have it installed) and run something like "wp search-replace 'https://OLD' 'https://NEW' --all-tables" before the export. Of course if you move things around a lot, it's not going to be quite as simple.

MarkupMenu is a markup module for generating menu trees. When provided a root page as a starting point, it generates a navigation tree (by default as a HTML "<ul>" element wrapped by a "<nav>" element) from that point onwards. If you've also provided it with current (active) page, the menu will be rendered accordingly, with current item highlighted and items rendered up to that item and its children (unless you disable the "collapsed" option, in which case the full page tree will be rendered instead). Modules directory: https://modules.processwire.com/modules/markup-menu/ GitHub repository: https://github.com/teppokoivula/MarkupMenu Usage As a markup module, MarkupMenu is intended for front-end use, but you can of course use it in a module as well. Typically you'll only need the render() method, which takes an array of options as its only argument: echo $modules->get('MarkupMenu')->render([ 'root_page' => $pages->get(1), 'current_page' => $page, ]); Note: if you omit root_page, site root page is used by default. If you omit current_page, the menu will be rendered, but current (active) page won't be highlighted etc. A slightly more complex example, based on what I'm using on one of my own sites to render a (single-level) top menu: echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'templates' => [ 'nav' => '<nav class="{classes} menu--{menu_class_modifier}" aria-label="{aria_label}">%s</nav>', 'item_current' => '<a class="menu__item menu__item--current" href="{item.url}" tabindex="0" aria-label="Current page: {item.title}">{item.title}</a>', ], 'placeholders' => [ 'menu_class_modifier' => 'top', 'aria_label' => 'Main navigation', ], 'include' => [ 'root_page' => true, ], 'exclude' => [ 'level_greater_than' => 1, ], ]); Note: some things you see above may not be entirely sensible, such as the use of {menu_class_modifier} and {aria_label} placeholders. On the actual site the "nav" template is defined in site config, so I can define just these parts on a case-by-case basis while actual nav markup is maintained in one place. Please check out the README file for available render options. I'd very much prefer not to keep this list up to date in multiple places. Basically there are settings for defining "templates" for different parts of the menu (list, item, etc.), include array for defining rules for including in the menu and exclude array for the opposite effect, classes and placeholders arrays for overriding default classes and injecting custom placeholders, etc. ? MarkupMenu vs. MarkupSimpleNavigation TL;DR: this is another take on the same concept. There are many similarities, but also some differences – especially when it comes to the supported options and syntax. If you're currently using MarkupSimpleNavigation then there's probably no reason to switch over. I'd be surprised if someone didn't draw lines between this module and Soma's awesome MarkupSimpleNavigation. Simply put I've been using MSN (...) for years, and it's been great – but there are some issues with it, particularly in the markup generation area, and it also does some things in a way that doesn't quite work for me – the xtemplates thing being one of these. In some ways less about features, and more about style, I guess ? Anyhow, in MarkupMenu I've tried to correct those little hiccups, modernise the default markup, and allow for more flexibility with placeholder variables and additional / different options. MarkupMenu was built for ProcessWire 3.0.112+ and with PHP 7.1+ in mind, it's installable with Composer, and I have a few additional ideas (such as conditional placeholders) still on my todo list. One more small(ish) difference is that MarkupMenu supports overriding default options via $config->MarkupMenu. I find myself redefining the default markup for every site, which until now meant that each site had a wrapper function for MarkupSimpleNavigation (to avoid code / config repetition), and this way I've been able to leave that out ? Requirements ProcessWire >= 3.0.112 PHP >= 7.1.0 If you're working on an earlier version of ProcessWire or PHP, use MarkupSimpleNavigation instead.

I have no experience with this Tribe events thing, so can't speak for that, but for the bulk of the content I'd recommend skipping the database export idea and going with the built-in REST API. While the REST API has its quirks, going directly to database for exports is going to be a major pain in the a*s in comparison. Not entirely unlike exporting ProcessWire content with raw SQL... ? It would be best to have a separate copy of the site at hand first, but after that it's basically as simple as installing the ACF to REST API plugin (which adds ACF field data to the REST API results) – and of course making sure that the REST API is enabled in the first place. You should be able to query and export all your pages, articles, and any custom post types with this method. Once you have the data, importing it to ProcessWire is going to be a breeze. (Note: based on some quick googling the Tribe events plugin also provides REST API support. I haven't used this, but it looks promising.) Also, in case that idea won't pan out, you can always rely on existing solutions, such as WP All Export (which provides a GUI for exporting content, including ACF data). Admittedly I haven't worked with this plugin before, but it's the companion plugin for WP All Import, the de facto standard plugin solution for complex imports. WP All Import is a bit of a monster and can feel clunky (hence devs often prefer custom imports for long-running, often-used, scheduled stuff), but for one-off cases it's a really handy tool. -- Edit: in case anyone is wondering, the WP REST API was first announced on June 17th 2013, which would be a week or so after Ryan started this thread. It didn't make it's way into the core until 2015, and even then it was for a very long time considered "a work in progress". It's been more than five years since this thread was started, so it shouldn't come as a big surprise that some things have changed ?

ProcessWire uses session_id() internally as well (in SessionHandlerDB), so by all means use that. I've never had any reason to actually work with session ID's in ProcessWire or heard anyone else asking for this, so my guess is that it's not a very common need, and as such Ryan hasn't felt the need to include a custom getter method for it in the Session class ?