On the Contentful blog they've posted the second part of their series reviewing static site generators for PHP. In this new article they look at Jigsaw, a Laravel-based tool.

In the first article of the series we took a look at Sculpin, the PHP static site generator which is currently the most starred on Github. Today we’re exploring Jigsaw, a tool which promises to bring a Laravel-based approach to the world of PHP static site generators (SSGs).

The author starts by sharing some about his (somewhat limited) experience with Laravel. From there he dives right in, showing the creation of a new Jigsaw site including configuration and how to serve it up locally. It then gets into detail about the directory structure of the site, asset handling and adding new content. The post ends by answering the "is it ready" question for their own needs (at Contentful).

If you're a user of the Jigsaw static site generation tool from Tighten, Matt Stauffer has a new post to his site that could come in handy. He shows how to automatically create a sitemap.

There are a few tasks that are still pretty tough with static sites—for example, search, and submitting forms (which we're trying to fix with FieldGoal). But there are other tasks that are tough-but-possible, and key among them are RSS and sitemaps. Let's start with sitemaps.

There was a feature recently added to help with this allowing you to add extra "hooks" to fire when the site builds. Matt makes use of this (and this package) to create a GenerateSitemap class that goes through each item in the site and adds a link to the sitemap.xml file. He shares the code for this class and the updates to make to the configuration and bootstrapping to correctly load the class.

On his site Joe Ferguson (maintainer of the Laravel Homestead project) has posted the first part of a "missing manual" series for Homestead. In this first part he covers the use of site parameters.

In the early days of Homestead there used to be a “params” option at the top level of your Homestead.yaml file. These parameters would be copied into the environment for the virtual machine just like you would set environment variables on your production systems. Laravel ultimately moved to using “.env” files and this feature was removed from Homestead.

Some users pushed back and still wanted to be able to easily push parameters to the individual site’s configuration file (virtual host file) so a new feature was implemented where you could add a “params” key to your Homestead.yaml site definition and they would be copied into the virtual host configuration file.

Joe then shows how to add the params section back into the Homestead.yaml file and get the settings loaded into the Homestead instance (involves destroying the Vagrant box and restoring it).

For those Sculpin users out there Matthias Noback has posted a tip showing how to make the tool skip certain sources so it's not included in the build. This is useful for removing files that may not be needed in the final result. In his case, he wanted to slim down his Docker image and only include exactly what was needed for the site it hosts.

Whenever I run the Sculpin generate command to generate a new version of the static website that is this blog, I notice there are a lot of useless files that get copied from the project's source/ directory to the project's output/ directory. All the files in the output/ directory will eventually get copied into a Docker image based on nginx (see also my blog series on Containerizing a static website with Docker). And since I'm on a hotel wifi now, I realized that now was the time to shave off any unnecessary weight from this Docker image.

After some searching around he found the best solution for his needs - a custom hook into Sculpin's own events system with a "before run" event. He includes the code he used to create a SkipSources event that uses pattern matches to exclude the requested sources. Then, using the fnmatch function he generated a listing of files to pass in to be skipped. After working up this solution, a bit more research also lead to another possible, more built-in way: the ignore configuration key that also uses pattern matching.

Matthias Noback has continued his series looking at using Sculpin to create static pages for "in-project documentation" with this second post focusing more on the creation of "virtual pages". These pages allow the insertion of dynamic content into pages pulled from other sources (in this case, from the source of the project).

Previously we looked at how to use the static site generator Sculpin to generate in-project documentation. When Sculpin builds the HTML files and assets it looks at what files are in the source/ directory and processes them based on certain rules (e.g. "parse Markdown files", "format HTML files with Twig", etc.). The purpose for my "living documentation" project is to also dynamically generate documentation based on PHP and configuration files from the main project.

[...] The Sculpin documentation mentions several ways to generate dynamic content for a static site, as opposed to the standard way of adding static Markdown or HTML files. [...] So, I dug into the source code of Sculpin to find out what would be a reasonable extension point. It turned out that the best way to approach this was to create a custom data source (which is currently not documented).

He then walks you through the creation of a custom data source with "dataSourceId" and "refresh" methods the tool uses to pull in the dynamic data. He shows how to set up the script to be called at any time and have the same effect (Sculpin does this when the "server" is running) and defining the service in your Sculpin configuration.

The SitePoint PHP blog has a new tutorial posted helping those Sculpin users out there get the most from their site with some helpful customization tips. Sculpin is a PHP-based static site generation tool that converts Mardon files and Twig templates into HTML documents ready for use.

If you’re a PHP developer and currently running a blog with a static site generator such as Octopress or Jekyll, wouldn’t it be great if you could use your primary language for it? Yes, it’s healthy for us developers to use more than one language, but let’s be honest – we often want to add some functionality to our blogs, but it’s difficult to accomplish in unfamiliar syntax. In this article, we’ll set up Sculpin, a static site generator for PHP. Just like any other static site generator, it uses markdown files and HTML templates to generate your blog, so the transition should be easy.

The tutorial starts by helping you get Sculpin installed (as a phar executable) and move it to where it's globally accessible. With that installed the article then helps you make a simple blog, customize some of the basic settings and start in on a new blog post. With that in place it then gets into the customization, adding in:

• syntax highlighting
• Disqus commenting
• blog archive links

The post finishes up showing you how to deploy the resulting blog into a GitHub pages repository and pushing them out for public consumption.

On the Tighten.co blog there's a new post introducing Jigsaw, a static site generator for Laravel developers they've created in the course of their own work.

That's right, Tighten has created a Laravel-based static site generator named Jigsaw, and we think it's pretty great.

Before I write another line of this post, I want to address the looming question: Why create another static site generator? In PHP alone there are two, and since we soft-launched Jigsaw there's already been another Blade-based static site generator launched.

The first part of the article lists three reasons for making the tool, pointing out the ecosystem they used (different from others), the focus on Laravel developers and the easy transition from a Jigsaw site to a full Laravel one. From there the post talks about what Jigsaw is and how you can get started using it (installation and configuration guide included). It also includes examples of "first pages" to help you get started and the result. The post finishes with a look at variable handling, custom front matter values, deployment and how to convert the site from Jigsaw to Laravel should the need arise.

In this post to his site Marko Pavlovic talks about REST APIs, some of the non-CRUD (create, read, update, delete) operations that need to be performed and how the Command design pattern can help.

We’ve all been here: the data model has been designed, and we have the entities and relationships implemented. It is finally time to code up the business logic and we are faced with solving these problems: The actions we want to implement on a particular model are not part of the good old CRUD (Create, Read, Update, Delete) operations, and we need to make a lot of non-standard controller actions, and routes. [Also] the actions we want to implement do not belong to a any model, and we have to create a new controller just for the "API".

He gives a more concrete example to illustrate the problem using "sites", "visits" and a desire to add analytics functionality using each's data. He points out two common actions taken when something like this comes up: either new methods on the pre-existing controllers or possibly making a new controller to handle it. Instead he suggests using the Command pattern to handle requests themselves as self-contained items. This gathers all the logic needed in to one place and the Report instance can then be used as-is by the response that needs to render the results.

On the SitePoint blog there's a tutorial posted showing you how to create a responsive site template in Spress, a static site generator written in PHP.

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).

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.