Leaderboard

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 ?

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!

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/

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 ?

As I understand it, „I prefer“ is not equal with „I never do“ or „I always do“. A single decission may be a compromise related to: possibilities, „costs“, and possibly available manpower compared to expected time expenditure. ?

Hello for all, ConfigurationForm fieldtype module is one my experiment from 2016. Main target to build this module was to store multiple setup and configuration values in just 1 field and avoid to use 1 db table to store just single "number of items on page", or another db table to store "layout type" etc. Thanks to JSON formatted storage this module can help you to reduce number of PW native fields in project, save DB space, and reduce number of queries at front-end. Install and setup: Download (at the bottom ), unzip and install like any other PW module (site/modules/...). Create some filed using this type of field (ConfigurationForm Fieldtype) Go to field setup Input tab and drag some subfields to container area (demo). Set "Name" and other params for subfields Save and place field to templates ("Action tab") How to use it: In my case, I use it to store setup and configurations values, but also for contact details, small content blocks... (eg. "widgets"). Basic usage example: ConfigForm fieldtype "setup" has subfields: "limit", type select, option values: 5, 10, 15, 20 "sort", type select, option values: "-date", "date", "-sort", "sort" // get page children (items) $limit = isset($page->setup->limit) ? $page->setup->limit : 10; $sort = isset($page->setup->sort) ? $page->setup->sort : '-sort'; $items = $page->children("limit=$limit, sort=$sort"); Screenshots: Notes: Provide option to search inside subfields Provide multilanguage inputs for text and textarea field types Provide option for different field layout per-template basis Do not place/use field type "Button" or "File input" because it won't works. Please read README file for more details and examples Module use JSON format to store values. Text and textarea field types are multilanguage compatible, but please note that main target for this module was to store setup values and small content blocks and save DB space. Search part inside JSON is still a relatively new in MySQL (>=5.77) and that's on you how and for what to use this module. Thanks: Initial point for this fieldtype was jQuery plugin FormBuiled and thanks to Kevin Chappel for this plugin. In field type "link" I use javascript part from @marcostoll module and thanks to him for that part. Download: FieldtypeConfigForm.zip Edit: 14. August 2018. please delete/uninstall previously downloaded zip Regards.

I've been doing a little rejigging of our default htaccess file after yesterday's dev release, and trying to understand Section 18 a bit better too... In section 18 we use a rule based on what is outlined here: https://processwire.com/blog/posts/optimizing-404s-in-processwire/ RewriteCond %{REQUEST_URI} !\.(jpg|jpeg|gif|png|ico|webp|svg|php|cgi|pl|asp|rar|zip)$ [NC] This is entered after the existing section 18 rules, which are left commented out. After the end of ProcessWire's htaccess rules we have: <FilesMatch "\.(jpg|jpeg|gif|png|ico|webp|svg|php|cgi|pl|asp|rar|zip)$"> ErrorDocument 404 "The requested file was not found. </FilesMatch> Without that rule, I get the ProcessWire 404 page when accessing a non-existent file matching one of those types. On a different htaccess-related note, I recommend the 6G htaccess Firewall https://perishablepress.com/6g/. We have this at the start of our default .htaccess file, followed by: ErrorDocument 403 "Sorry, you are not permitted to access this resource. The only issue I've come across after a few years of use is with the autocomplete Page field, when using OR selectors (e.g. template=home|default). I wrote this hook as a remedy: <?php // Replace pipes (|) with %7C in PageAutocomplete data-url attribute // This gets around 6G htaccess rules which disallows pipes in urls $wire->addHookAfter("InputfieldPageAutocomplete::render", function(HookEvent $event) { $out = $event->return; if(strpos($out, "data-url") === false) return; $url = explode("'", ltrim(explode("data-url=", $out)[1], "'"))[0]; $event->return = str_replace($url, str_replace(" ", "+", str_replace("|", "%7C", $url)), $out); }); Cheers, Chris

@teppo - that is what I thought, but I was thrown by the comment for that rule: "After uncommenting, test a URL like domain.com/site/assets/files/test.jpg to make sure you are getting a 404 and not your homepage." Those conditions don't seem to prevent apache from serving up a test.jpg at that path, although it occurs to me just now that Ryan's intention was for test.jpg to be a file that doesn't actually exist - makes sense now! I was also confused by the "prevent PW from attempting to serve images or anything in /site/assets/" - I thought he was talking about subfolders of assets as well. My initial thought was that this rile was actually about preventing hotlinking, so I think I got the intention backwards, hence my confusion ?

Yeah I know - I had a LOT of work to do to fix the queries on a large custom application of mine, but from the reading I did at the time, it was a highly recommended change to better ensure you're getting the results you were expecting. Mine was very data / calculation heavy though, so maybe not as important for typical PW queries.

One little hackish way around this is to redirect to the same page with "?livepreview=1" appended to the URL: <?php namespace ProcessWire; if(!$_GET['livepreview']) { $session->redirect($page->url."?livepreview=1"); } Good enough for my use-case.

Hi @ryan, Thanks for the update. The section 15B update to .htaccess is nice. I'm keen to enable that on my sites as it's a good bit of extra security. But I just want to check: does this blocking only apply to files that are accessed directly by the browser and not those served by PW via $files->send()? Because on several sites I offer downloads of a set of CSV files that I build and bundle into a ZIP file on-the-fly. I create the ZIP in a WireTempDir and then send the file for download via $files->send(). So would this be affected by section 15B? I did a quick test and it seems to work okay but just want to confirm that I don't need to adjust that section of .htaccess to allow WireTempDir paths.

I have had MS Office 365 the last couple of years just for the storage of 1TB which turned out to be not more than 6GB which is super comfortable to use on Google's Drive option - even for free accounts. I made the switch to Google One in the last weeks to move company data there and well... now we pay 20 EUR/year instead of ~60 EUR/year and due to "welcome vouchers" can use everything vom G Suite as well for at least the next 2 years - which is totally fine. ? MS Office Online works pretty well on Linux but still not as good as the installed versions of Word, Excel and every other app provided by Microsoft. No matter which OS you use. Libre and Google Drive can handle UTF8 and everything Calc/Excel-related way better than Microsoft itself. Strange but true. Handling data within Libre or Google is way more easy than in any MS product out there. Even clients like the simplicity of it. To be honest... I miss XD a bit... but for now... I'm almost as fast in prototyping in HTML/CSS as in XD. Weird but it works and it's way more closer to the final result as in XD. I never used Sketch but XD is nice. My Surface still runs Windows 10 so if I ever feel the need of using any Adobe product, I can switch cables and use another device for it. For now... the switch to I3WM and some modifications (aaaaaaaa lot!) later I feel way more productive than all months and projects before.

Sounds nice, we built some similar (but highly customised on some special internal needs...). But found many very similar things in it. ?

Therefore I used this in the past: https://processwire-recipes.com/recipes/change-homepages-default-language/ Maybe it works in your case as well.

I just installed mySQL 5.7.26 and switched to that version - everything works just fine (Laragon, Windows).

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

Meanwhile in Vienna ?

I just want to share my findings from today when I wanted to create one million pages quickly: First, via Tracy Console: ini_set('max_execution_time', 150); $last = $pages->findOne("parent=/data,include=all,sort=-id"); $last = (int)$last->title ?: 0; for($i=$last+1;$i<$last+1000;$i++) { // create page $p = new Page(); $p->template = 'basic-page'; $p->parent = '/data'; $p->title = $i; $p->save(); l("saved page $i"); $pages->uncacheAll(); gc_collect_cycles(); } d('done'); It started at 23 pages per second: And at the end of the 150 seconds it was already down at 4 pages per second: Testing without logging: Memory usage also increased proportionally. Finally running a PHP script from the command line that bootstrapped PW worked well: <?php namespace ProcessWire; $time_pre = microtime(true); include("../../../index.php"); // bootstrap ProcessWire $last = $pages->findOne("parent=/data,sort=-id"); $i = (int)(string)$last->title ?: 0; // multilang quickfix convert to string // foreach($pages->find('parent=/data') as $p) { // $p->delete(); // echo "deleted $p\n"; // } // return; $i++; $num = 0; while($i <= 1000000) { // create page $p = new Page(); $p->template = 'basic-page'; $p->parent = '/data'; $p->title = $i; $p->save(); $pages->uncacheAll(); gc_collect_cycles(); $num++; echo "done: $num ($i)\n"; $i++; } function convert($size) { $unit=array('b','kb','mb','gb','tb','pb'); return @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i]; } $time_post = microtime(true); $t = $time_post - $time_pre; $m = memory_get_usage(); echo "created $num pages in " . round($t, 3) . "s, " . round($t/$num, 3) . "s per page, used " . convert($m) . " memory\n"; Benefits: quick runs in the background and does not lock the site direct feedback via echo without creating huge log files cancel via ctrl+c any time easy persistant saving of your scripts

I will never understand how people can live with Win10 bricking updates, privacy breaking telemetry, and a desktop maze.

Hi all, This is probably a stupid question but is there anyway to select from the database all the images as Pageimage objects? The idea being so that I could have just a 1 level deep array of Pageimage objects so that I can loop through and run the removeVariations() method on them? My original idea was something along the lines of: $query = $this->database->prepare('SELECT name FROM FIELDS WHERE TYPE = "FieldtypeImage"'); $query->execute(); $results = $query->fetchAll(); foreach ($results as $row) { $query = $this->database->prepare('SELECT * FROM FIELD_'.$row[0]); $query->execute(); $images = $query->fetchAll(); foreach($images as $image){ // my thinking was at this point if said results where Pageimage objects or // could be turned into one I could then run the removeVariations() method on them ie. // $image->removeVariations() } } I tried working with the above results within my module code but I could never get them into the correct context to run the method in question. The above implentation obviously doesn't work but is the idea sound? Could it ever work in this fashion or do you only have access to Pageimage::removeVariations() in the context of starting with a page selection ie. $page->image->removeVariations(); The reason I ask is that I have a solution using the built in selectors which partially works. However it comes up short when attempting to remove the image variations for image fields within repeaters, theres also the issue of images fields within nested repeaters. Any ideas are much appreciated.

Thats exactly the kind of thing I was looking for! ? If im ever anywhere near Munich i'll buy you as many beers as you can drink ?

hi, Old thread but I've just tested with MySQL 5.7.14 on PW 3.0.42 and did not encounter any problem so far.

In a related topic in the ProFields sub-forum @ryan has said: So please log any SQL mode issues at GitHub as they arise so they can be tracked and resolved.