Sebastian De Deyne has a new post to his site showing the Laravel users out there a method for theme-based views in their applications using vendor namespacing in a multi-tenant environment.

I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.

Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.

[...] There aren't any huge issues here, but all together it feels like we should be able to do better. There are a few strategies to clean this up, but I just want to talk about vendor namespaces today.

He gives an example of a view setup that makes use of the current client/customer's namespace to define the path to the template. He found this leading to a lot of redundancy and figured out a better way: using namespaces. Namespacing is mainly made for package development but can be use here to create a "theme" namespace. This namespace can then be defined once and reused across the application without the need to manually build the template location string every time.

On the CloudWays blog there's a new tutorial posted showing you how to create project documentation with Sami, a tool that takes the DocBlock information already in your code and makes it into something more human-readable.

Developers regularly create large blocks of code that form parts of API’s and other mid to large level projects. While there is a (more or less) agreed upon convention for code writing, every developer has a personal comment and documentation writing standards. Some add small cryptic notes while others attach full-length Google Docs that document the method or class in painful details. This problem becomes very severe when the number of end users increases and there is a need for proper documentation of the project.

[...] DocBlocks are important because they are used by a well known Symfony document generator package called Sami. Very popular in PHP community, Sami also provides the ability to create custom twig templates and work with versioned documentation on GitHub. In this article, I will use Sami and a GitHub project Sync Mysql data with Elasticsearch to automatically generate documentation.

The tutorial then helps you get the Sami package installed via Composer and how to execute it to ensure it's working as expected. Next it points you to a project to clone to help with the MySQL-to-Elasticsearch interface. It then helps with the creation of a configuration file, the results of a build and some additional tips for customizing the configuration for your environment.

The SitePoint PHP blog has another post in its series about working with Drupal 8. In this new tutorial author Daniel Sipos talks about theming views in the content management system and introducing custom style plugins.

In this article, we are going to look at how we can create a custom Style plugin for Views in Drupal 8. We will use the Bootstrap tab markup as a goal and implement a tabbed output for our View results. In the View configuration, the Style settings will allow us to specify which field will be used as the tab navigation copy, leaving the rest of the fields shown in the respective tab panes. Basically, each View result will represent a tab – so this example is not suited for Views which have more than a few results. The main goal is to illustrate how we can create our own Views Style plugins in Drupal 8.

He starts by talking about Style plugins - what they are and where they fit in the application execution flow. He then walks you through the creation of the custom style plugin to integrate the Bootstrap tabs. This also includes the creation of the theme and the matching template to build out the tab markup.

You may have heard of Sculpin – a static site generator for PHP. [...] While easy to use and fast to set up, Sculpin’s development has stagnated a bit and the documentation leaves much to be desired. Spress is, in a way, its spiritual successor. Much better documentation, much more flexible configuration, much easier to extend, and just as easy to use with almost the same API and commands.

He starts by helping you set up a basic site to work with on a Homestead Improved instance. Once that's up and running (including an install of Spress) he creates the simple site and starts in on the rebuild of the Svbtle theme. He briefly explains how Spress themes work and then includes the code/layouts you'll need to reproduce the theme. The post includes a screenshot of what the end result should look like in two different browser sizes (responsive, remember).

If you are a Drupal developer who has dabbled in theming older versions of Drupal (5, 6, 7) you understand why frustration is the trusty companion of any Drupal themer. Luckily, though, Drupal 8 promises so many improvements that even the Angry Themer is happy for a change. It is only natural we jump in and start looking at what these improvement are.

On the Drupalize.me site they've posted a guide to getting started with Drupal 8 based on the boilerplate code that already comes with the release.

Drupal 8 represents a lot of changes and a steep learning curve for many Drupal developers and themers. While many of these changes are exciting, there are many things to learn just to get started. One way to learn about the code involved with Drupal 8 modules and themes is to take a look at core's modules and themes for examples to follow. Another is to use a code-scaffolding tool like Drupal Console to generate boilerplate code and comments that you can learn from and then customize.

He makes the assumption that you already have a development environment set up and working then helps you install the Drupal Console for use in the rest of the tutorial. You can then use this command line tool to create a new Drupal 8 installation and generate the boilerplate code for a new theme. Finally, they show the creation of the two other related components: a new module and a block plugin instance. These are generate generic code you can use as a reference point for either updating your current Drupal projects or create new ones.

The SitePoint PHP blog has a new post in their series covering the OctoberCMS today, this time looking at how to create a custom theme. They walk you through the creation of a simple "blogging" theme type with posts, categories and home/about pages.

October CMS is the new star in the sky of CMSes. Built on top of Laravel, it promises joyful coding and a back to basics approach. Read our introduction here and find out how to build plugins for it here. In this article, we’re going to see how we can build a theme.

Their theme makes use of the rainlab plugin allowing for the use of Markdown content in your posts. They start by adding in the directories and base files needed for the theme to the "themes" directory. With the plugin installed they start working through the configuration content and setup of the theme files including PHP and markup sections. He also shows how to use placeholders, partials and layouts in the content of the posts. Next is the static pages, About and Home, with a bit simpler configuration. The code is then included for the remainder of the pages: single posts, categories and the post listing.

In this episode we don't have a specific theme. We do however have a lot of fun content for you. We discuss Magnus' trip to Symfony Live New York, the Best Practices document, Blackfire.io (née SensioLabs Profiler) and much more. We also have a long interview with Jordi Boggiano of Composer fame, and two short interviews with Jeremy Mikola and Anne-Sophie Bachelard respectively.

On the Sanisoft blog there's a recent post that gives you a step-by-step guide to working with themes in the upcoming version 3 release of the CakePHP framework.

Almost every application I code has themes which either the end user can change or the admin can set or can be changed on the fly. Doing all these things was easy in CakePHP 2.x. With the first alpha release of CakePHP 3.x I was naturally keen to try out how theming worked with V3.

He shows how to convert an existing theme into one that will be compatible with the 3.x version of the framework. He breaks it down into seven steps (well, technically eight) to make it easier to follow along:

If you haven't visited the main PHP.net site in the last day or two, you may have missed it but they've officially released the new look for the site, a more modern look for both the manual and rest of the site.

The PHP web team are delighted to announce the launch of the new web theme that has been in beta for many months. Lots of hard work has gone into this release and we will be continually improving things over time now that we have migrated away from the legacy theme.

From an aesthetics point of view the general color scheme of the website has been lightened from the older dark purple. Lots of borders and links use a similar purple color to attain consistency. Fonts are smoother, and colors, contrast and highlighting have significantly improved; especially on function reference pages. Code examples should now be much more readable.

This new version updates the technologies used as well, including HTML5, Google Fonts and the Twitter Bootstrap. Go take a look at the new version and, if you spot any issues or bugs in it, be sure to report the problem on the PHP bug tracker.