Jump to content
bkno

From a security & maintenance point of view, how often should a updates be installed?

Recommended Posts

Hi,

I'm new to PW and like it a lot so far. With most WordPress and Drupal websites there are frequent updates to core & plugins, some of these are security released so I tend to install any updates ASAP. When supporting many websites this update fatigue is pretty tiresome.

What is your update strategy when maintaining PW sites? Would be interested to hear if you think it is valid to perhaps do a quarterly update or perhaps only even update yearly if there are no security announcements?

Also just to clarify, if there a security mailing list we should subscribe to just in case an urgent fix is ever released?

Thanks!

Share this post


Link to post
Share on other sites

By now there aren't any known security issues with processwire core, so updating is purely needed for accessing new features. There's also no mailing list for security. The best is to follow the weekly blogposts by any of the available channels.

  • Like 1

Share this post


Link to post
Share on other sites

Howdy @bkno, and welcome to the forum.

ProcessWire itself is very secure, in that there have been few, if any, security related updates. In fact, I am not aware of any such update in the couple of years I have been using ProcessWire. Consequently, there isn't a security mailing list like what you have become familiar with in other platforms.

As far as an upgrade regiment is concerned, if you stick with the latest master version you should have no issues. For those times that you do wish to upgrade, the procedure is very simple and as a result, not anywhere close to being tiring as with the other cms/cmf you have worked with. And the only real reason you might upgrade is when new functionality becomes applicable to your site.

The modules that you can install are created by the community, and should be treated as any user-defined content. As with any publicly accessible resource, it is up to the developer to guard against malicious intent. ProcessWire provides a number of tools to assist you, such as sanitizing data submitted by your users. That being said, the community members here are very knowledgeable and very experienced, and again, I am not aware of any security issues with the modules they produce.

The previous security issues you experienced is why I also left those other environments. I have had no disappointments or regrets moving to ProcessWire. In addition, you can browse any topic in this forum and see the quick and accurate support provided by the community members.

I don't intend for this to sound like a sales pitch. I'm only stating the facts as I have come to know them. 

 

There ya go. @LostKobrakai is one of those community members. He beat me to the post. Again. :)

Edited by rick
  • Like 3

Share this post


Link to post
Share on other sites

Welcome to the forum @bkno

Just one consideration to add to the others written above: most likely you will only be forced to update an otherwise smoothly running ProcessWire website when the PHP version it is running on becomes obsolete and the new PHP version you wish to upgrade to has deprecated methods no longer supported/available but some functionality of your old ProcessWire depend on those deprecated PHP functions, meaning you will need to update your ProcessWire core and other modules in order to keep up with the changes in PHP.

Sure, it is a general issue with PHP based websites, but since you asked how frequently you need to update, I think it is worth pointing out that due to the nature of PHP one day you will be forced to update or at least want to update if some PHP security flaws emerge in no longer supported PHP versions.

Other than that, you do not have to update at all :) That being said, I recommend updating when you need new features provided by the core or when you want to upgrade to a PHP version which dictates the need of upgrading ProcessWire.

Hope this helps.

  • Like 1

Share this post


Link to post
Share on other sites

Many thanks all! Happy to be here.

Very encouraging to hear - this will enable updates to be done during active development phases with a site, so there can be a general round of testing rather than trying to test everytime after installing frequent updates.

I'll check out the upgrade module.

  • Like 1

Share this post


Link to post
Share on other sites

One thing i'd like to bring up is the fact that because the design of your website is separate from the back end and content of your website upgrades don't break your website.

This is the largest bugbear I have had with WordPress and I no longer do ANY sites with it. It's as if a WordPress site has a lifespan - after a year or 2 I dreaded upgrades to the theme (yes even with child themes) as any update could break my client's site. Even plugin updates could break the site. And a site lasting more than 3 or 4 years - I haven't had one yet. Most of the sites I ran were designed by designers (I handled the back end) always with modifications - and I don't think I have particularly picky customers. Its just WordPress sites are so generic out of the box that you have to modify the theme.

These days I have a designer do me a homepage and an internal page (saving me money compared with them doing the full site) and I implement the pages with various page layouts, blogs - whatever I want. Anything WordPress could have done I can do - though it can take some PHP programming to get what I want. (but I do get EXACTLY what I want)

And I never have to worry about updates. I just noticed a site I was working on from last year was ver. 2.7 and as it's going live I decided that I'd send it off with the latest version. Update to 3.0.63 took less than 5 minutes (and that included taking a backup of the database)

Give Processwire a try - there is a bit of a learning curve on your first few sites but after that (and easily reusing code) you'll never look back.

 

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By VeiJari
      Hello forum, this is my first security related post, so I'm a bit of a newbie.
      I understand that when I have direct front-input from user I should sanitize the input, but how about when I use a secret key for showing a API for a third-party supplier? Should I sanitize the input->get() key?
      I've tested this issue and I tried ?key=<?php echo $page->field; ?> And without adding any sanitization it comes back: /?key=<?php%20echo%20$page->field;%20?>
      So can I rely on this, or should I still use $sanitizer just in case?
       
      Thanks for the help!
    • By anttila
      We have many booking calendars made with ProcessWire (own databases) and I want to do a web app (SQL) which allows user to log in. First, the user chooses the right calendar and then (s)he have to log in. The user can be from any of those calendars and the app is not running on ProcessWire (it can if necessary). So if there any way to make sure that the user has rights to the calendar (s)he tries to log in and if the password is correct.
      Is there any better way to do this? I could also use PIN codes or something, but those need to be encrypted too.
      Multiple ProcessWires A lot of users per ProcessWire Everyone can log in to the web app (when using right calendar)
    • By MoritzLost
      I've been working with ProcessWire for a while now, and I've noticed that using Composer to manage dependencies and autoload external libraries isn't as prevalent in ProcessWire development as in other areas of PHP programming. I started out by using the default setup recommend in this blogpost. However, one major problem I have with this approach is that all external dependencies live in the webroot (the directory the server points to), which is unfavourable from a security standpoint and, in my opinion, just feels a bit messy.
      In this tutorial, I want to go through a quick setup of Composer and ProcessWire that keeps the dependencies, all custom-written code and other source material outside of the webroot, and makes full usage of the Composer autoloader. This setup is pretty basic, so this tutorial is probably more useful to beginners (this is why I'll also include some general information on Composer), but hopefully everyone can take something away from this for their personal workflow.
      Site structure after setup
      This is what the directory structure can look like after the setup:
      . ├── composer.json ├── composer.lock ├── node_modules │   └── ... ├── public │   ├── index.php │   ├── site │   ├── wire │   └── ... ├── packacke-lock.json ├── package.json ├── sass │   ├── main.scss │   ├── _variables.scss │   └── ... ├── src │   ├── ContentBag.php │   └── ... └── vendor ├── autoload.php ├── composer ├── league ├── symfony └── ... As mentioned, the main point of this setup is to keep all external libraries, all other custom source code and resources out of the webroot. That includes Composer's vendor folder, your node_modules and JavaScript source folder if you are compiling JavaScript with webpack or something similar and including external scripts via NPM, or your CSS preprocessor files if you are using SASS or LESS. In this setup, the public directory acts as the webroot (the directory that is used as the entry point by the server, DocumentRoot in the Apache configuration). So all other files and directories in the mysite folder aren't accessible over the web, even if something goes wrong.
      One caveat of this setup is that it's not possible to install ProcessWire modules through Composer using the PW Module Installer (see Blogpost above), but that's just a minor inconvenience in my experience.
      Installation
      You'll need to have composer installed on your system for this. Installation guides can be found on getcomposer.org.
      First, open up your shell and navigate to the mysite folder.
      $ cd /path/to/mysite/ Now, we'll initialize a new Composer project:
      $ composer init The CLI will ask some questions about your projects. Some hints if you are unsure how to answer the prompts:
      Package names are in the format <vendor>/<project>, where vendor is your developer handle. I use my Github account, so I'll put moritzlost/mysite (all lowercase). Project type is project if you are creating a website. Author should be in the format Name <email>. Minimum Stability: I prefer stable, this way you only get stable versions of dependencies. License will be proprietary unless you plan on sharing your code under a FOSS license. Answer no to the interactive dependencies prompts. This creates the composer.json file, which will be used to keep track of your dependencies. For now, you only need to run the composer install command to initialize the vendor directory and the autoloader:
      $ composer install Now it's time to download and install ProcessWire into the public directory:
      $ git clone https://github.com/processwire/processwire public If you don't use git, you can also download ProcessWire manually. I like to clean up the directory after that:
      $ cd public $ rm -r .git .gitattributes .gitignore CONTRIBUTING.md LICENSE.TXT README.md Now, setup your development server to point to the /path/to/mysite/public/ directory (mind the public/ at the end!) and install ProcessWire normally.
      Including & using the autoloader
      With ProcessWire installed, we need to include the composer autoloader. If you check ProcessWire's index.php file, you'll see that it tries to include the autoloader if present. However, this assumes the vendor folder is inside the webroot, so it won't work in our case.
      One good place to include the autoloader is using a site hook file. We need the autoloader as early as possible, so we'll use init.php:
      EDIT: As @horst pointed out, it's much better to put this code inside the config.php file instead, as the autoloader will be included much earlier:
      // public/site/config.php <?php namespace Processwire; require '../../vendor/autoload.php'; The following also doesn't apply when including the autoloader in the config-file.
      This has one caveat: Since this file is executed by ProcessWire after all modules had their init methods called, the autoloader will not be available in those. I haven't come across a case where I needed it this early so far; however, if you really need to include the autoloader earlier than that, you could just edit the lines in the index.php file linked above to include the correct autoloader path. In this case, make sure not to overwrite this when you update the core!
      Now we can finally include external libraries and use them in our code without hassle! I'll give you an example. For one project, I needed to parse URLs and check some properties of the path, host et c. I could use parse_url, however that has a couple of downsides (specifically, it doesn't throw exceptions, but just fails silently). Since I didn't want to write a huge error-prone regex myself, I looked for a package that would help me out. I decided to use this URI parser, since it's included in the PHP League directory, which generally stands for high quality.
      First, install the dependency (from the project root, the folder your composer.json file lives in):
      $ composer require league/uri-parser This will download the package into your vendor directory and refresh the autoloader.
      Now you can just use the package in your own code, and composer will autoload the required class files:
      // public/site/templates/basic-page.php <?php namespace Processwire; use \League\Uri\Parser; // ... if ($url = $page->get('url')) { $parser = new Parser(); $parsed_url = $parser->parse($url); // do stuff with $parsed_url ... } Wiring up custom classes and code
      Another topic that I find really useful but often gets overlooked in Composer tutorials is the ability to wire up your own namespace to a folder. So if you want to write some object-oriented code outside of your template files, this gives you an easy way to autoload those using Composer as well. If you look at the tree above, you'll see there's a src/ directory inside the project root, and a ContentBag.php file inside. I want to connect classes in this directory with a custom namespace to be able to have them autoloaded when I use them in my templates.
      To do this, you need to edit your composer.json file:
      { "name": "moritzlost/mysite", "type": "project", "license": "proprietary", "authors": [ { "name": "Moritz L'Hoest", "email": "info@herebedragons.world" } ], "minimum-stability": "stable", "require": {}, "autoload": { "psr-4": { "MoritzLost\\MySite\\": "src/" } } } Most of this stuff was added during initialization, for now take note of the autoload information. The syntax is a bit tricky, since you have to escape the namespace seperator (backslash) with another backslash (see the documentation for more information). Also note the PSR-4 key, since that's the standard I use to namespace my classes.
      The line "MoritzLost\\MySite\\": "src/" tells Composer to look for classes under the namespace \MoritzLost\MySite\ in the src/ directory in my project root. After adding the autoload information, you have to tell composer to refresh the autoloader information:
      $ composer dump-autoload Now I'm ready to use my classes in my templates. So, if I have this file:
      // src/ContentBag.php <?php namespace MoritzLost\MySite; class ContentBag { // class stuff } I can now use the ContentBag class freely in my templates without having to include those files manually:
      // public/site/templates/home.php <?php namespace Processwire; use MoritzLost\MySite\ContentBag; $contentbag = new ContentBag(); // do stuff with contentbag ... Awesome!
      By the way, in PSR-4, sub-namespaces correspond to folders, so I can put the class MoritzLost\MySite\Stuff\SomeStuff in src/Stuff/SomeStuff.php and it will get autoloaded as well. If you have a lot of classes, you can group them this way.
      Conclusion
      With this setup, you are following secure practices and have much flexibility over what you want to include in your project. For example, you can just as well initialize a JavaScript project by typing npm init in the project root. You can also start tracking the source code of your project inside your src/ directory independently of the ProcessWire installation. All in all, you have good seperation of concerns between ProcessWire, external dependencies, your templates and your OOP-code, as well as another level of security should your Server or CGI-handler ever go AWOL. You can also build upon this approach. For example, it's good practice to keep credentials for your database outside the webroot. So you could modify the public/site/config.php file to include a config or .env file in your project root and read the database credentials from there.
      Anyway, that's the setup I came up with. I'm sure it's not perfect yet; also this tutorial is probably missing some information or isn't detailed enough in some areas depending on your level of experience. Feel free to ask for clarification, and to point out the things I got wrong. I like to learn as well 🙂
      Thanks for making it all the way to the bottom. Cheers!
    • By Jennifer Stock
      Greetings. I would like to restrict access to certain sections of my organization's ProcessWire site using pubcookie. We are rolling out Shibboleth authentication later this year but for now, it seems I can only make use of our institution's single sign-on routine by utilizing rules in an .htaccess file. 
      I am wondering if there is a way to ask PW to apply these rules to certain pages in the site, whether via template type or location in the page tree:
      AuthType UWNetID PubcookieAppID "MyApplication" require type staff faculty  
    • By flydev 👊🏻
      Presentation
      Originaly developped by Jeff Starr, Blackhole is a security plugin which trap bad bots, crawlers and spiders in a virtual black hole.
      Once the bots (or any virtual user!) visit the black hole page, they are blocked and denied access for your entire site.
      This helps to keep nonsense spammers, scrapers, scanners, and other malicious hacking tools away from your site, so you can save precious server resources and bandwith for your good visitors.
       
      How It Works
      You add a rule to your robots.txt that instructs bots to stay away. Good bots will obey the rule, but bad bots will ignore it and follow the link... right into the black hole trap. Once trapped, bad bots are blocked and denied access to your entire site.

      The main benefits of Blackhole include:
       Bots have one chance to obey your site’s robots.txt rules. Failure to comply results in immediate banishment.
       
      Features
      Disable Blackhole for logged in users Optionally redirect all logged-in users Send alert email message Customize email message Choose a custom warning message for bad bots Show a WHOIS Lookup informations Choose a custom blocked message for bad bots Choose a custom HTTP Status Code for blocked bots Choose which bots are whitelisted or not  
      Instructions
      Install the module Create a new page and assign to this page the template "blackhole" Create a new template file "blackhole.php" and call the module $modules->get('Blackhole')->blackhole(); Add the rule to your robot.txt Call the module from your home.php template $modules->get('Blackhole')->blackhole();  Bye bye bad bots!

      Downloads
      https://github.com/flydev-fr/Blackhole http://modules.processwire.com/modules/blackhole/  
      Screen

       

       Enjoy
×
×
  • Create New...