On the Laravel News site they've posted a quick tutorial showing how to add in "maintenance mode" management functionality into Laravel Nova, the recently released administration panel product for Laravel-based applications.

If for some reason you’ve been on another planet (see what I did there?), Laravel Nova is Now Available and the community has been rather busy building open-source tools around Nova.

One of those open-source tools is by David Piesse, who created a Laravel Nova extension that allows you to manage the maintenance mode of your application from Nova

The package to add the functionality is easily installed via Composer and integrate via a service provider. This then adds a new toggle to the administration panel's UI to enable or disable maintenance mode (as well as an icon showing the current status).

The Delicious Brains site has posted the final part of their "Hosting WordPress Yourself" series to their site. In this latest tutorial they cover ongoing maintenance tasks for your server to keep it running smoothly and secure.

So you’ve followed our in-depth guide and built yourself a shiny new server that’s secure and tuned for optimal WordPress performance, but what’s next? In this installment of Hosting WordPress Yourself, I’m going to outline a few tasks that should be carried out on a regular basis to ensure that your server continues to run securely and perform well. We’ll look at performing software updates, upgrading PHP, and a few “gotchas” to watch out for that we may have experienced ourselves. Let’s dive straight in!

The article is broken up into several sections, each with a summary providing a bit more background:

• Keep Plugins and Themes Updated
• Check Backups are Running
• Keep an Eye on Server Metrics
• Watch Those Log Files
• Update Server Packages
• Upgrade PHP

They also talk about upgrading the OS itself (Ubuntu) and how to outline an action plan that, when used regularly, can keep your system and software up-to-date easily.

The WordPress project has posted a new release that includes some security fixes and general maintenance changes.

WordPress 4.8.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

WordPress versions 4.8.1 and earlier are affected by [several] security issues.

Issues include problems with prepared statements in SQL statements, XSS issues in several features, path traversal vulnerabilities as well as open redirect flaws. It's recommended that all WordPress users upgrade to this release to prevent exploit of these vulnerabilities either by downloading the latest release or by upgrading via the internal dashboard.

On the Toptal.com site they've posted a guide that aims to help you write good code that stands the test of time. They provide six "commandments" that they think can help make your code better and easier to maintain in the future.

Specifically, “good code” is code that is easily and readily maintainable by an organization (not just by its author!) and will live for longer than just the sprint it was written in. The following are some things I’ve discovered in my career as an engineer at big companies and small, in the USA and abroad, that seem to correlate with maintainable, “good” software.

Their list includes suggestions like:

• Treat Your Code the Way You Want Other’s Code to Treat You
• Good Code Doesn’t Reinvent the Wheel, it Stands on the Shoulders of Giants
• Don’t Cross the Streams!
• When Possible, Let the Computer Do the Work

Each item on the list comes with a brief description with a bit more detail and how to apply it to your development. It's not focused on any one language, however, so there's no code samples here - just links to other resources and tools that can help in their application.

Alex Bilbie has an interesting new post to his site looking at the idea of open source guilt. He uses the term to describe the feeling you can get when a project falls by the wayside and you're not putting as much effort into it as you had before. He uses his own real-world project work as an example (an Oauth2 server and client).

I've willingly and happily poured hours of my life into both projects. [...] After leaving the university I moved to London and my life "got flipped-turned upside down" (as Will Smith once put it) which naturally resulted in a reduction in the number of commits that went into the projects. [...] I did my best with the emails piling up in my inbox but I also ignored many. [...] Releasing open source projects is a great feeling however there are a number of considerations one should bear in mind.

He makes the suggestion of four things to keep in mind when working on and releasing an open source project. These are things that can remind you (and keep you away from) some of the issues he's had in his own work:

• Actions have consequences
• People want to help
• Your personal reputation is on the line
• Popular open source projects work well when the authors are using the project regularly themselves

He also includes a few personal things he's going to do to try to make life easier and happier including roadmaps for projects, documenting via FAQs and being more honest about his own availability.

In the latest post to the SitePoint PHP blog Bruno Skvorc proposes the idea that "legacy code is a cancer" that can influence decisions and technology choices that shy away from the new and possibly more functional alternatives.

This might come out controversial, but I firmly believe there is no room for legacy code in modern systems. Allow me to elaborate before you sharpen your pitchfork and light your torch. What I mean by that is: there should be absolutely zero reason to keep implementing the functions you’re adding to the new version retroactively into the old version, just because some people are still using it, even if the people using it are a vast majority.

He talks about the "support everything for as long as we can" ideal and how it can come back to bite you in the end. He suggests that, at some point, the v1 users have to "be discarded" and dropped for the upgraded version of the application. He talks about failure potentially brining around success and compares applications versus libraries and components and the upgrade path for each. He ends the post with a suggested upgrade path to move the system itself away from legacy support and into the new, latest version.

Paul Jones has shared some of his thoughts about framework tradeoffs in his latest post. In it he compares two perspectives about framework use for beginners - either the "get something out there" product approach or focusing on the the long term maintenance of the product.

Phil Sturgeon at his blog, writing about product creators who neither know nor care much about programming as a discipline. [...] Phil’s post focuses on the joyful, proud moments of creation that lead to business success, whether in terms of venture funding or continued sales. In this essay, I want to focus on what happens after that, when that initial creation passes into other hands to be maintained.

Paul talks about how frameworks can allow developers to work "beyond their level" and be more productive than they could be otherwise. He points out that this can create a beginner-level codebase that works "just enough" and then is usually passed off to more experienced developers to update, change and flat out fix issues.

From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. Indeed, the product creator may justify his failures of good programming practice by substituting the product popularity and continued rounds of funding as a marker of success. [...] But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.

Matthew Setter has posted five reasons why he thinks that making a coding standard is an essential part of your development process. He suggests that "pain avoidance" is one of the key factors, both for new members of the team and for those maintaining it in the future.

Whenever you’re working on a project, are you consistent? Are you consistent in your coding style, consistent in your documenting, consistent in your database naming conventions? Better yet, do you and your team have a coding standard which you consistently adhere to? If you don’t, you’re buying yourself and others a world of pain – which is painlessly simple to avoid. Today I’m banging the drum, shouting from the street corner, calling from the cathedral spire, imploring you to do one thing, above all else – pick a coding standard and then BE CONSISTENT!

His five reasons for implementing (and effectively using) a coding standard are:

• Poor, Inconsistent Code - Causes You Pain
• Your Code is Easier to Read
• Your Code is Easier to Understand
• Your Code is Easier to Maintain
• Your Code is Easier to Collaborate on

Check out the post for summaries of each point.

In a new post to his blog Lee Davis describes the enum conundrum - what's the right solution for effectively using ENUM-type fields in your data?

So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I’ve heard they’re evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.

Tom Schlick has a new post to his blog talking about a tool he's written for FuelPHP-based applications called Wrench. It's a command-line tool to make taking your site "offline" simpler.

If you have been following what I've been up to lately you would see that many of my recent projects are based on FuelPHP. Since Fuel is so awesome and allows you to create "packages" that can be dropped into your application, I have created a few that help me quickly piece together apps. The first package I'm "releasing" is called Wrench.

The tool works with the oil command-line tool already included in the framework to swap out the default action with a "Down for Maintenance" message. It will look at the current state of the app and switch it to the opposite when run, but you can also define "start" and "finish" manually if you'd like. You can find the source for the package on Tom's github account.