Michael Dryrynda has a post to his site sharing a method for using Laravel Telescope in specific environments. Telescope provides enhanced debugging functionality to Laravel applications for introspection into data about requests, jobs, queues and more.

Whilst its primary purpose is as a debugging tool in development, it is also a powerful asset in debugging your production environment. In order to get Telescope, however, I ran in to some stumbling points in my CI environment in GitLab.

To work around this, I set out to conditionally load Telescope. I stumbled upon this comment from Mohamed Said, which suggested loading the TelescopeServiceProvider in one of your application's service providers, but doing so was not enough.

He goes on to talk about the package auto-discover functionality Telescope uses to load its provider and how this, along with the dont-discover configuration option in Composer's extra section can be used to control its loading. He also includes the code needed to register the provider classes but only in the environments other than "build" and "testing".

The Laravel News site has a tutorial posted that approaches a common development task - writing tests - from a data-driven approach rather than a strictly functional one.

Testing your code is an essential part of the development process, but sometimes it could also be expensive when you try to emulate many uses cases based on a set of different input data.

In many cases, you could end up with a massive directory of tests repeating the same block of code over and over for each possible user interaction.

They start with an example of a feature to test (Markdown parsing) and how traditional testing would have methods for each of the transformations. With a data-driven approach they turn the tests around and make use of data providers to set up the initial string, transformer to use and the correct result. Code is included showing an example of this kind of testing for the same Markdown parsing example and what a failure would look like in a dataset with multiple items.

On the Pineco.de site they've posted a tutorial showing you how to use the Laravel framework to generate PDFs with content provided from the system. To accomplish the content-to-PDF conversion, they make use of the dompdf library.

PDF generation is a core feature when our app contains invoicing or services that require a downloadable version of an information schema. Like in many other situations, a simple solution would do it instead of a full-featured package. Let’s see how to render PDFs easily.

Once the package is pulled in via Composer they add in a custom configuration to handle some of the basic settings including the paths to the fonts, the paper size and what DPI to use to render the final product. With that in place the post starts in on creating the custom PDF service, extending the Dompdf class and adding in a bit more Laravel-specific functionality for the service. After explaining this code they move on to updating the container to include the service via a provider and show the creation of a simple PDF controller. This controller uses the service to generate PDF output from the data in their invoice object and stream the results directly back to the client.

On the TutsPlus.com site they've posted a new tutorial showing you how to register and use service providers in Laravel and how it relates to the service container functionality.

If you've ever come across the Laravel framework, it's highly unlikely that you haven't heard of service containers and service providers. In fact, they're the backbone of the Laravel framework and do all the heavy lifting when you launch an instance of any Laravel application.

In this article, we're going to have a glimpse of what the service container is all about, and following that we'll discuss the service provider in detail. In the course of this article, I'll also demonstrate how to create a custom service provider in Laravel.

The article starts with an overview of the service container and service providers, describing what they are and providing some example code/configuration to clarify the concepts. It then gets into the creation of your own custom service provider. In their case they create a provider that doesn't really do anything but it does help to show how to make it, register it and put it to use in a controller.

Cal Evans has continued his series covering Mautic, the PHP based self-hosted marketing automation platform. This is step one in the process with his previous post in the series introducing Mautic and why he's trying it out.

This is the second post in a series titled “My Journey into Mautic”. If you are starting here, you might get an incomplete picture, you may want to check out the previous articles.

There are two things that really confuse me about Mautic, properly configuring an Email Service Provider (ESP), and segmenting & tagging. We’ll tackle the latter one in a later post, but the former is an important topic. It is also one that I do not fully understand. What is presented here is what I have learned through trial and error. it my be partially or wholly incorrect. If you find something that I’ve gotten wrong, please, by all means, correct me in the comments.

He starts by defining what an ESP service is and what it's useful for. While he had done the self-hosted email server in the past, he recommends paying for a service these days, deciding for his needs on Mailgun. He covers the difference between transactional and broadcast emails followed by the setup process he followed to get Mailgun up and working with his Mautic install.

On the Tighten.co blog there's a recent post showing off some of the magic of Laravel macros and how they can make extending the basic framework functionality simpler.

Ever wanted a piece of functionality in a part of Laravel that doesn’t exist? Let me introduce you to Laravel macros. Macros allow you to add on custom functionality to internal Laravel components.

He gives an example of adding a simple "introduce" macro on the Request facade and how to put it to use. He refactors this into something more useful: returning a true/false result when checking the TLD on the current domain. He includes the code to set up the macro in the AppServiceProvider and the addition of an enhancement that adds a "where" clause to a model query when the TLD matches. He wraps up the post giving some guidance on where they should be defined and what components in the Laravel framework are "macroable".

The Zend Framework blog continues their series of posts looking at the Zend Expressive framework with this latest tutorial showing you how to use configuration-driven routing instead of routes defined in just code.

Expressive 1 used configuration-driven pipelines and routing; Expressive 2 switches to use programmatic pipelines and routes instead. The programmatic approach was chosen as many developers have indicated they find it easier to understand and easier to read, and ensures they do not have any configuration conflicts.

However, there are times you may want to use configuration. For example, when you are writing re-usable modules, it's often easier to provide configuration for routed middleware, than to expect users to cut-and-paste examples, or use features such as delegator factories.

Fortunately, starting in Expressive 2, we offer a couple different mechanisms to support configuration-driven pipelines and routing.

They start by pointing out the result of the Expressive v1 to v2 migration tool (enabling v2's pipeline handling) and a warning that there could be issues as the programmatic declarations still remain. The tutorial then gets into some of the drawbacks of going configuration-only but shows how, with just a bit of extra code, those can be someone relieved. An example is included showing a configuration provider that, from the functionality itself, defines the routes and injects them into the current application (using injectRoutesFromConfig).

In this recent post to his site Barry van Veen introduces you to providers in Laravel applications and how they relate back to the built-in service provider.

Currently, I'm working on my first Laravel package. So, it was time to dive into the wonderful world of the service container and service providers.

Laravel has some great docs about, but I wanted to see some real-world examples for myself. And what better way than to have a look at the packages that you already depend on?

This post details the different things that a service provider can be used for, each taken from a real open-source project. I've linked to the source of each example.

He starts off talking about (and linking to) the current provider documentation and includes a basic example of adding the provider to your configuration. He then covers several different pieces of functionality that can be used inside the providers including:

• binding of singletons and instances
• setting up aliases
• registering dependencies
• adding in additional resources

There's also a few "other" things included showing how to defer loading, set up event listeners and adding in a new Blade directive.

The Master Zend Framework site has a new tutorial posted helping you simplify the configuration on your Zend Expressive application with the help of ConfigProviders, a handy feature that lets you split up the configuration into logical "chunks" as PHP classes.

Given Zend Framework’s design (and accompanying flexible nature), this [configuration complexity] can easily be the case if we’re not careful. [...] Specifically, we’ll likely end up with a config/autoload directory polluted with a plethora of configuration, including for dependencies, routing, and middleware.

[...] As it turns out, this was something which was already identified by other developers, including the Zend Framework contributors. [...] In there, he mentioned ConfigProvider classes as a simple way of enabling ZendForm ViewHelpers, which aren’t enabled by default in Zend Expressive. As I looked at the composition of the file, I realized that this was the answer I needed to solve the configuration issue I created for myself.

A screencast is included in the post showing off the solution but the code an explanation are below that as well for those more interested in reading than watching a video. He walks you through the creation of the configuration provider including setting up the dependency configuration, updating the route handling and, finally, actually using the provider in your global configuration.

In this post to his site Djordje Kovacevic shares the results of his evaluation of hosting providers in the platform-as-a-service arena for hosting PHP applications: OpenShift, Heroku and Fortrabbit.

I want PHP 5.6+, so I did some basic testing of those services to pick cheep and good solution to host my blog. OpenShift because I use it and it's free for 3 small gears, it was pretty good solution few years ago. Heroku because I used it for Ruby on Rails projects and they support multiple languages (even multiple build packs for one project)! I used FortRabbit too, so I decided to test theirs new apps.

For his testing he used a simple Laravel (v5.2) application with a handful of routes - something simple just to test out the setup and deployment processes. There is a "tl;dr" of the results but he also gets a bit more in-depth on what each service has to offer and some of the pros and cons of each. He also includes the results of some basic performance testing on the instances, linking to the raw output if you'd like to run your own metrics against it.