Leaderboard

It's more about server/hosting security than validation as it happens server-side and before any request reaches ProcessWire. ProcessWire works out of the box in about 95-99% situations already. Maybe not in case of NGINX but that's another thing. Knowing more about systems and their configuration isn't a bad thing at all. I don't want to miss anything I know about servers and how to handle them. Have you ever installed Typo3? It is (or at least was) pain in the a** and they still have a nice market share. I'm more afraid of doing my taxes and still I have to deal with it. There are professionals for those things. I wouldn't spend too much time and effort in replacing some lines in the .htaccess file. Why bother with something that's already working almost all of the time? Debugging those installation or migration issues within the core of a CMS is way more difficult than (un-)commenting some lines in a plain-text file. And to be honest... I'm quite shocked that WordPress has just a few lines in its .htaccess. Last but not least... In my opinion: No... I think the .htaccess could do even more in some cases. For example: https://processwire.com/blog/posts/optimizing-404s-in-processwire/

A simple module to enable easy navigation between the public and the admin side of the site. After installation a green bar will appear to the upper side of the screen, containing a few navigation elements and displaying the PW version number. Heavily inspired by @apeisa's great AdminBar (Thanks!). I needed a bit simpler tool for my projects and as a result, this was made. Available on GitHub .

So there are a few things to unpack: You essentially removed exactly what's needed to know when working with an .htaccess file being unfamiliar with apache. There are like two setting in there, which are rather common to change: rewrite base (shared hosters often need it set) and https. That's it. Everything else is either static or only to be touched in certain corner cases. If you have rules to let files be directly accessed by the webserver (and not route through php -> bad performance) then you might want to disallow certain folders, which should not be accessable. Things like caches or logs are prone to leak important information about your website and simply allowing any file in the system to be accessable (see wordpress) is not good practice at all. Also this is not stuff that can be handled by the core, because you don't want php involved for static files, but you also want not all static files be accessable. For an example: Say you deploy your composer.json (you shouldn't, but well) with all the other files of your project. People could happily look for you using packages with known security issues and you'd even aid them, by telling them what version constraints you've set up. It was also already noted that for laravel most of the important stuff is not even web accessable by default, because only it's public folder is meant to be served by a webserver. This is not possible for processwire again because of shared hosters, where often you don't have the possibility to store files outside the webroot to begin with. That I can support. Nginx configs provided by the core would be really nice and would probably make ProcessWire more approachable for the usecases, where people rent own servers and want e.g. the performance of nginx. I'd say "the conversion" is scary without knowledge. I can understand that. But the plain presence of an a-bit-longer .htaccess didn't bother me much even before I knew what any of it did. You won't even notice in most cases as the instructions to install are basically: Download processwire, unzip and open url. There are cases where that's not enough, but it's certainly a big majority where this will just work. This is ill driven as like 95% of those rules wouldn't even hit the core without serving static files through php are things not changeable by php at all. So my final comment would be: The current .htaccess is usefully more elaborate than certain other systems. It makes it more complex to port to other systems, but it's 50% just a bunch of regexes to secure certain files/folders, so I'd say it's more tedious work than a to difficult one.

Okay I get your point. I made a 30 lines CSS Only switcher that should work with other theme than UiKit : https://codepen.io/flydev/pen/QYYZVL

A lot of the rules protect direct HTTP access to sensitive files such as config, logs, sessions, templates... most other frameworks and CMS's keep this sensitive stuff out of the web root, so HTTP based access is not possible by design. In ProcessWire, the root directory equals the web root directory, so we need to protect access to these files. On the plus side, ProcessWire can be installed on hostings that do not allow to change the web root. The drawbacks are that we need to be extra careful that nobody can access sensitive/private files.

I would because Ryan did not wrote in his blog post that it is a requirement not to move the 404 page. Yes please ?

Hey @bernhard - sorry about that - it didn't work as you expected. Please try the latest version which lets the Console panel work as a guest when you use the "logout" option via the User Switcher and also it now works on localhost when using the "Force guest users into DEVELOPMENT mode on localhost" which should take care of @Robin S's request above. Hopefully the next version will include the new Tracy core features along with some other tweaks - just need to find some time ?

It's strange that the location of the 404 page would affect the trash. An alternative way to hide the 404 page instead of moving it is to hook Page::listable() $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->id === 27) $event->return = false; }); I actually like to go a bit further than this, and say that if a page is in the top level and is hidden and the user doesn't have edit access for the page then it is of no concern to them and they don't need to see it in Page List: $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->parent->id === 1 && $page->isHidden && !$page->editable) $event->return = false; }); In my case I give the 404 page a dedicated template that non-superusers do not have edit access for, and so it is hidden in Page List.

Thanks again for the responses, @Wanze, @wbmnfktr, @Autofahrn, and @LostKobrakai. All of your answers (again) help me make sense of things I didn't know or understand as fully as I thought I did. I've thought for a long time that the .htaccess file that ProcessWire uses was way more robust (read: better) than other CMS' that don't hide most of the app outside of webroot, but I hadn't thought about necessity of most of it. I think all of my thoughts/worries have been sufficiently addressed.

@britnell You can also take a look at my twilio module if that helps.

Usual way is something like this in your module (adjust to suit your needs): /** * @return array */ static public function getDefaultConfig() { return array( "my-module-config-1" => "", "my-module-config-2" => "", "my-module-config-3" => "my default setting for this config field", ); } /** * Populate default configuration (will be overwritten after constructor with user's own configuration) * */ public function ___construct() { foreach(self::getDefaultConfig() as $key => $value) { $this->$key = $value; } } /** * @param array $data * @return InputfieldWrapper */ public function getModuleConfigInputfields(array $data) { $inputfields = new InputfieldWrapper(); $defaults = self::getDefaultConfig(); $data = array_merge($defaults, $data); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-1'; $f->label = __('MyModule key 1'); $f->value = $data['my-module-config-1']; $f->collapsed = 5 ; // collapsedPopulated $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-2'; $f->label = __('MyModule Config key 2'); $f->collapsed = 5 ; // collapsedPopulated $f->value = $data['my-module-config-2']; $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->name = 'my-module-config-3'; $f->label = __('MyModule config key 3'); $f->collapsed = 5 ; // collapsedPopulated $f->value = $data['my-module-config-3']; $inputfields->add($f); return $inputfields; } Then you can call it in your template like: <?php $myModule = $modules->get('MyModule'); ?> <p><?=$myModule->my-module-config-1?></p> Best way to learn is to look into other popular PW custom modules ?

Hi Peter, It's hard to find something without the logs and the phpinfo() result, we can only make assumptions. What say the logs ? Could be something related to the PHP Garbage Collection mystery.. Hard to tell at this point and even worse with shared host. Also, it's possible that Plesk have a script run by a CRON job which delete sessions EACH HOUR, that could be the issue too! ask your host about that or look into your panel. A suggestion before starting scratching your head by modifying some values in the php.ini file would be to test the same form submission but with a different session handler configured, eg, SessionHandlerDB and SessionHandlerRedis. Setting up the last one for testing is quite simple, configure the Redis server on your computer to listen all interface (::1), open the right port (6379 by default) in your firewall/box and set the connection information in the config.php of your website, done, test it now. And as always, if you want me to have a ninja session on your server settings, ping by PM ?

Hi Ben, I'm still interested as long as it is also about admin side messaging out of the box.

Visual Page Selector version 006 (released (18/02/2019) Happy to announce that the latest release of Visual Page Selector is now available for Download/Purchase. Thanks to suggestions by @Macrura, this version includes a number of improvements one of which will require clients to relearn one thing (sorry). Changelog Ajax vs Manual Save: You can now choose whether pages added to inputfield should be immediately saved to the pagefield (via Ajax) [the default behaviour] versus have them added in a sort of "pending state". If the latter, pages will be added to the inputfield (for visual purposes) but will not be saved to the pagefield until the page you are editing is manually saved. In the modal, visually, the pages are presented as if they are in the field (i.e. similar to pages saved in the field). In the inputfield, a pending page behaves like other pages saved in the field; they can be reordered, edited, etc. This feature has several advantages including the fact that changes can be made to the page without immediately being reflected in the frontend. Please note that reloading the page being edited without saving will discard pending pages! The setting is in the Input Tab (Modal Settings) when editing the field. Trash Icon: VPS Inputfield (Thumbs View) now behaves like a PW image field in relation to deleting pages in the page field. To delete an image from a PW image field, the process simply involves marking an image for deletion by clicking on its trash icon and saving the page. Previously, VPS (Thumbs View) has required two steps (in multi-page fields); first to mark an image for deletion by clicking on its trash icon and finally clicking on the remove icon (x). In single page fields, there was no icon altogether. It required clicking on the remove icon (x). Hence, these similar actions behaved differently from each other and from PW image fields (which VPS in Thumbs View seeks to emulate and enhance). With this update, VPS now behaves similar to PW image fields across the board. To remove pages from a pagefield using VPS, simply click on their trash icons and save the page. We have removed the remove icon (x). Unfortunately clients will have to be re-taught about this change but I think the benefits outweigh the inconvenience. Modal Lister View: We've improved the visibility of pages selected for adding to a VPS inputfield. The light grey background did not provide enough contrast. We've gone for a light red (pink?).

For those interested - looks like the Tracy core will be getting multiple AJAX bars in v3: https://github.com/nette/tracy/pull/336#event-2144817375 This will be great for many reasons and will also let me remove my additive approach to dumps in the AJAX bar because consecutive requests will show the dumps on separate bars, rather than overwriting the last one which is how the core currently works.

Any updates on this? I've been occupied lately, but spotted some details too. A seperate repo would be awesome. I've referenced the Ember kind-of-way before (including their awesome RFC process), but I also like their approach to a volunteer based website on github. Also checkout the README with other public repositories too. All community / PR merge request based.

Anyone still interested in this module? Also the module saves all messages in plain text, would you be interested in a encrypted version of the module using key exchange or hash keys?

Relying on .htaccess is not really uncommon for php cms's out there. Some are more minimal on utilising apache, processwire is probably more on the "take what we can get"-side. Having php serve everything – especially static assets – is just not performant enough in any way. That's the reason for needing to rely on the webserver in front of php in the first place. The reason for apache specifically is because of .htaccess. Other webservers are usually only statically configurable, which is a deal-breaker for any shared-hoster, where a (global) webserver cannot be restarted whenever a single user needs to change his configuration. So if you only support one webserver, it better be apache.

Using .htaccess is efficient. You could, in theory, handle (nearly) everything in PHP, but this would add serious overhead, both memory and speed wise. Others have adapted the rules for NGINX, a few like me use IIS with URL Rewrite to power PW, but in all cases, it makes sense to filter and rewrite requests in the web server itself. The topic of supporting more platforms than just Apache out of the box has been brought up a few times already here in the forums. Ryan himself is not opposed to it, but he lacks the time to develop and test the rule sets, and he is of course wary of including anything that hasn't been well tested or that might end up without active support (any changes he makes for .htaccess need to be quickly adapted for other platforms). So I guess it would need a team of knowledgeable volunteers who develop the rules, adapt the installer script, test everything well and provide quick support before he considers integration into the PW project.

This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new $page->if() method— https://processwire.com/blog/posts/pw-3.0.126/

Sorry I haven't had the chance but just had a look. I solved it without regex in v0.6.1 and the exact template name is checked. I have only tested it thoroughly so be aware ?

Maybe watching something similar helps: https://www.youtube.com/watch?v=_d0hZ8iS344 I'm thinking of logged in users being able to post messages in the PW backend which supports remote collaboration, or support developers by providing some means to announce changes made to the site. Currently if users want to communicate, PW does not support them at all.

Thanks adrian! Yeah, I kinda overlooked the author field the first time, my bad ^^ Curious issue ... anyway, thanks for your help!

I've made those changes for you. I guess you couldn't edit because you didn't set an author when you first submitted the module. The interface is pretty clunky at the moment. Hopefully Ryan will improve it with the revamp.

Now I see. It does not show, because I have moved the 404 page under "admin", as suggested by kongondo. If I reparent the 404 Page under "home" again the trashcan is showing for my "editor". Strange. Would you say it's a bug? Shall I report it? Thank you.

All my test sites run from a virtual server managed by Plesk with NGINX in front of apache. Never had to bother with any configuration details, PW installs without any special attention to .htaccess or similar. It simply works out of the box for me.

It doesn't work because your wildcard SSL certificate in the format "*.example.com" only matches one "level" of subdomain, so it's not valid for www.subdomain.example.com, see https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain The redirect directives look good to me, Apache doesn't care about how many subdomains you're matching in the RewriteCond. But the browser cares about the invalid SSL certificate. The redirection won't work in this case, because the browser won't accept the SSL certificate, as it's not valid for www.subdomain.example.com. Since the SSL handshake and certificate validation takes places before the redirect headers are followed, the browser will show the security warning before doing anything else. I'd wager that if you manually add a security exception, the redirection will work. If you want to redirect https traffic to another https URL, you need a valid certificate for both the domain originally requested by the client and the target of the redirection, or the browser will show the security warning before or after the redirect, so your solution with the additional SSL certificate is the only one that can work. Why do you even need to support the second www subdomain? Sounds like one of "those" client requests ?

Do you mind giving me a description of your use case, look back over your comments but still cant quite get my head around it.

Hi All, I'm new to developing in PHP and Processwire so apologies in advance for any stupid questions. I'm working on developing a module for the Twilio Channels API. I'd like to be able to input the API credentials into the modules settings page and then call the API credentials in module functions and, where necessary, in templates. I can currently add the API details and save them in my module config file, no problem. ModuleConfig file: <?php class TwilioChannelsConfig extends ModuleConfig { public function getDefaults() { return array( "id" => "", "token" => "", "from_number" => "" ); } public function getInputfields() { $inputfields = parent::getInputfields(); $f = $this->modules->get('InputfieldText'); $f->attr('name', 'id'); $f->label = $this->_('Twilio SID'); $f->notes = $this->_('From your Twilio Account (at https://www.twilio.com/user/account)'); $f->columnWidth = 50; $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->attr('name', 'token'); $f->label = $this->_('Twilio API Token'); $f->columnWidth = 50; $inputfields->add($f); $f = $this->modules->get('InputfieldText'); $f->attr('name', 'from_number'); $f->label = $this->_('Your Twilio Number'); $f->description = $this->_('Will be used as the "from" number when sending messages or starting calls.'); $inputfields->add($f); return $inputfields; } } What I'd like to be able to do is either call getInputFields() in a template, something similar to this: $moduleConfig = $modules->get('TwilioChannelsConfig'); echo "<p>" . $moduleConfig->getInputFields('id') . "</p>"; or to call the credentials to my .module file. I've tried a few different approaches but can't get it to work. Not sure what I'm missing. Thanks in advance for any help.

So, yes, this method unzips all nested files. My use case, for anyone who may need: <? // hook into tutorial upload and unzip file into destination wire()->addHookAfter("InputfieldFile::processInputFile", function(HookEvent $event) { $pagefile = $event->argumentsByName('pagefile'); // limit to a specific field {file_tutorial}, restricted to zip uploads if($pagefile->field->name != 'file_tutorial') return; // full disk path to your custom uploads directory $tutorialsBaseDirectory = $this->wire('config')->paths->assets . 'tutorials/'; // extend path with custom directory nam corresponding to page id $pageIdDirectory = $tutorialsBaseDirectory . $pagefile->page->id . "/"; // extend path with custom directory name from the filenme without extention $tutorialDirectory = $pageIdDirectory . $pagefile->basename($ext = false); // use ProcessWire's $files API // @see: http://processwire.com/api/ref/files/ $files = $this->wire('files'); // Remove directory and its files after ensuring $pathname is somewhere within /site/assets/ $files->rmdir($pageIdDirectory, true, [ 'limitPath' => $tutorialsBaseDirectory ]); // make tutorials id directory correspondig to ressources id if($files->mkdir($tutorialDirectory, true)) { // directory created: /site/assets/tutorials/id/filenameWithoutExtension } // get zipfile and destination and unzip $zip = $pagefile->filename; $dst = $tutorialDirectory; $items = $files->unzip($zip, $dst); }); Adopted from The script takes an uploaded zip and unzips it into the destination folder. As it has an index.html I can point a link to it.

Thank you all for your answers! It was very exploratory because this is a blind spot for me. I haven't known exactly how this worked, and after all of the explanations, I think I understand a little more fully. Thanks!

Just in case someone else stumbles over this, you'll need to modify these lines at the end of method format() in TextformatterPrism.module: $markup = $dom->saveHTML($dom->getElementsByTagName('body')->item(0)); $markup = ltrim(rtrim($markup, '</body>'), '<body>'); Into this: $markup = $dom->saveHTML($dom->getElementsByTagName('body')->item(0)->nodevalue); Reason is, that ltrim/rtrim do not trim strings but character groups. So they do not stop after the <body> tag but continue to strip any following char if its one of "<>bdoy"... Using nodevalue (or textcontent) from the body element eliminates the need for the trim.

Probably worth pointing out that currently the "safe thing to do" is going with 7.1 or 7.2: 7.0 is no longer officially supported, so it's no longer receiving security updates, and even 7.1 will stop receiving (security) updates near the end of this year. 7.3 is currently the "cutting edge" version, so you might want to wait a while before going there. In terms of security there are exceptions, such as Ubuntu, where distro maintainers have been backporting security-related fixes from new versions to old ones – but if you're already on 7.0, I would assume that it's not the one that you got with your operating system, and as such is likely that you're already using a (potentially) insecure version.

OK, this is my current solution: (only works in UIKit admin theme)

Ok, Thanks berhard, I'll give that a try. I think a blank profile might be more straightforward at this point. Then I'll see if I can figure out how to plug it into the other setup. Cheers, Gavin

Try this one: Please note that the \t and \n need cleaning up. function buildMenuFromObject($parent = 0, $menu, $first = 0) { if(!is_object($menu)) return; $out = ''; $has_child = false; foreach ($menu as $m) { $newtab = $m->newtab ? " target='_blank'" : ''; // if this menu item is a parent; create the sub-items/child-menu-items if ($m->parentID == $parent) {// if this menu item is a parent; create the inner-items/child-menu-items // if this is the first child if ($has_child === false) { $has_child = true;// This is a parent if ($first == 0){ $out .= "\n<ul class='uk-navbar-nav'>"; $first = 1; } else { $out .= "\n\t<div class='uk-navbar-dropdown'>" . "\n\t\t<ul class='uk-nav uk-navbar-dropdown-nav'>"; } } // active/current menu item $class = $m->isCurrent ? ' class="uk-active"' : ''; // a menu item $out .= "\n\t<li$class><a href='{$m->url}{$newtab}'>{$m->title}</a>"; // call function again to generate nested list for sub-menu items belonging to this menu item. $out .= buildMenuFromObject($m->id, $menu, $first); if ($m->isParent) $out .= "\n\t</div>\n";// close div.uk-navbar-dropdown $out .= "</li>"; }// end if parent }// end foreach if ($has_child === true) $out .= "\n</ul>"; return $out; } // example usage $mb = $modules->get('MarkupMenuBuilder'); $menuItemsAsObject = $mb->getMenuItems(1041, 2); $menu = "\n<div class='uk-navbar-center uk-visible@m'>"; $menu .= buildMenuFromObject(0, $menuItemsAsObject); $menu .= "</div>\n"; echo $menu;

Version 0.5.0 fixes two issues, please update: Fix wrong url in the <link rel="alternate" hreflang="x-default"> meta tag. Fix date formatting for the lastmod property in the XML sitemap. Cheers

I remember there being a Caddy container with PW somewhere. You could try searching on hub.docker.com and pulling the image to see how it's set up. Sorry, I don't have any resources to help here.

If you don't change JS + CSS all the time, consider local tools like Grunt, Yarn, Gulp, Webpack etc. IDEs like PHPWebStorm can do LESS/SASS -> CSS compilations too.

Thanks @adrian I think I got it sorted out. New version 1.0.4 is pushed.

I would love to know what happened. Let me know, if I need to, I will issue an update right away. Thank you!

Fresh install of PW 3.0.62, I'm getting this error when installing the latest version of Recurme: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /var/sites/t/X/public_html/wire/core/Modules.php on line 3921 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0 Never seen this before and I'm a bit stumped... Any ideas? Edit: Increased memory limit with ini_set on the module to see where this goes and got a 30s execution time error. Can't figure this one out, there must be a loop somewhere as increasing that came back to a 800MB memory limit! Edit 2: Solved! I'll send you an e-mail with details.