The Laravel News site has posted the latest part of their "Building a Laravel Translation Package" series focusing on a pre-launch checklist of items to get in place before it's finally released.

In the last part of the series, we finished up building the Laravel Translation package. With this completed, we are ready to start thinking about releasing the it to the world. However, before we do, there are few important steps we need to take.

The post covers some of the final non-code items to take care of:

• Good documentation
• Defining contribution guidelines
• Providing issue templates for easier reporting of bugs/issues by others
• Selecting a license
• Setting up continuous integration for running tests, checking code style, etc.

Each item in the list includes a brief summary of what's involved and, for some, links to other resources and tools that can help get it accomplished.

On the Laravel News site they've posted the latest tutorial in their series covering the creation of a translation package. In this latest article they cover the creation of the database driver to replace the previous file-driven content handling.

In the previous article of the series, we talked about how to handle missing translations, which brings us very close to making the package feature complete. To finish up the build phase of this series, we will discuss how we go about adding a database driver.

Thanks to defining the interface for the data handling previously, redefining the handler for the database is simpler. He includes the code for:

• the migrations to create the languages and translations tables
• the models for both tables and their relations to each other
• creation of the database driver using the interface

His code includes methods for getting either single or multiple translations including fetching them by language. He then updates the "resolve" method to allow defining the driver to use in the configuration rather than being hard-coded.

The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

The Laravel News site has posted the latest in their "Building a Laravel Translation Package" series of tutorials with a new post focusing on the frontend and getting it connected to the backend functionality.

In the last installment of this series, we talked through the process of manipulating the translations in our application’s language files into a format where we are now in a position to start interacting with them. In this article, we’ll be wiring up the frontend ready to start building out the user interface which will aid users with the process of translation management.

The UI will be developed using the community favorites, Tailwind CSS and Vue.js.

The tutorial starts with the approach for the functionality, taking a more hybrid approach and using a balance of backend and frontend for the majority of the functionality. It then starts in on the technical parts to connect the two halves:

• adding the required routes
• creating the controllers
• building out the views to render the interface

The majority of the post is then dedicated to the creation of the assets - the Javascript and CSS - to create the "framework" the functionality will use to work with the translations.

Sameer Nyaupane has posted the latest part in his "PHP Test Driven Development" series of tutorials. In this latest post, part five, he focuses on integration testing, ensuring the components are all working together as they should.

Let’s learn about Integration testing today. Integration testing is a method of testing by passing in the real dependencies and thus testing out the integration between two or more objects.

He updates the examples from his previous post to test the integration between the Math and Calculate classes. He walks you through the changes required to the phpunit.xml configuration and the creation of the initial test classes. He goes through each line of the tests, explaining what it's doing and how mocks are used to help with dependencies.

On the Laravel News site they've continued their "Building a Laravel Translation Package" series of tutorials with the latest article covering the "wrangling" of the translations themselves.

As we’ve discussed earlier in the series, out of the box, Laravel translations are stored in language files. These can be either PHP array-style syntax or straight up JSON files.

[...] The plan for the package is, much like many features of Laravel, to expose multiple drivers to power the translation management. The first driver will utilize Laravel’s existing file-based translations with plans to later add a database driver.

[...] The file driver needs to interrogate the filesystem in order to return the data in the required format. This involves a lot of filtering, mapping and iterating, so we will lean quite heavily on Laravel’s collections.

The tutorial is then divided up into a few different parts, each for a chunk of the package functionality around translation management:

• listing languages
• adding languages
• listing translations
• adding/updating translations

Each item in the list comes with a summary of the feature and a few lines of code showing how to implement it.

The StarTutorial site has posted the latest in their "Modern PHP Developer" series of posts outlining some of the more recent changes to PHP and its ecosystem that can help you become a better developer. In this latest post they focus on Exceptions in PHP - the types, handling them and when they're most useful.

Since PHP 5 was released, Exception is added to PHP as an object-oriented programming language feature. By definition, an Exception is an exceptional event during program execution. In PHP, an Exception is simply an object (an instance of Exception class). When an exception occurs, PHP will halt current execution flow and look for an handler, and then it will continue its execution by the handler's code. If no handler is found, a PHP Fatal Error will be issued with an "Uncaught Exception ..." message and the program terminates.

The tutorial is then broken down into several parts:

• When to use Exception
• How to use Exception
• Create your first custom exception 5.3
• SPL exceptions
• RuntimeException

For each item in the list, there's a summary of the topic and code examples to help illustrate the points made.

On the DeliciousBrains.com site they've posted the latest installment for their "Hosting WordPress Yourself" series (part 12) showing how to move your WordPress installation over to a new server.

In part 11 of Hosting WordPress Yourself I demonstrated how to update a server’s packages (including PHP). However, I didn’t show how to upgrade the server itself, because it’s not something I recommend.

[...] In this article, I’m going to walk you through the steps required to migrate an existing WordPress site to a new server. These are the same steps that I took just a few months ago to migrate the Delicious Brains site to a new server with little to no downtime.

The rest of the article is broken up into several different sections, each with descriptions and commands/code you'll need:

• Securely Copying Files
• File Migration
• Nginx Configuration
• HTTPS Certificates
• Spoof DNS
• Database Import

They also include hints on migrating with minimum downtime and things to look out for when you "flip the switch".

Christopher Pitt has kicked off a new series of posts to his site covering the creation of a new blog system. It's not just any blogging system, however. In this system he's developing it as an asynchronous application using preprocessing. In the introduction to the project he fills in more of the details:

I’ve been building this blog, for a few days now, and it’s been a fun experience. This is partly because it’s an asynchronous application, and partly because it uses a lot of preprocessing.

I thought it would be interesting for me to describe how it is put together, in an ad-hoc sort of series. In the series, I’ll show bits of code and links to libraries I’ve used. I’ll talk about why I’ve chosen to do things in certain ways, and what I could improve (short of deleting everything and starting over with a mature framework).

In this first part of the series, he includes a "tiny bit of code" showing a component of the system before the preprocessing has been run. He's also posted the second part of the series that continues covering the functionality for handling "posts" in more depth (including the use of flat files for content storage and functionality to output Markdown content as HTML).

The Laravel News site has continued their series of posts covering the creation of a Laravel translation package with part two of the series. In this latest article they build on part one's introduction and start to build out some of the scaffolding for the package.

In Part 1, we introduced that this series would cover the process of building and maintaining an open-source package for Laravel. Check it out for an overview of what we’ll create in this series. Next, we are going to get to work on scaffolding a new Laravel package.

The post then walks you though the basics of scaffolding a package including:

• repository setup
• Composer configuration creation
• defining the package structure
• the creation of a service provider
• testing

Examples of the Composer configuration are included but the remainder of the points will be developed over the next several parts of the series.