2.0 RC1 released!

Chyrp version 2.0 release candidate 1 is out! To upgrade, back up your .yaml.php files, overwrite your old install, restore them, update your official modules, and run the upgrader. Read More »

Documentation Requests

I’d like to get started with documenting Chyrp. Not just the internals, but how it works and why, what its capabilities are, where things are located, etc. We are currently using the wiki system that github provides, and a few articles are already up, but it’s nowhere near finished. What I’d like to know is what documentation you guys want, so I can get that done first and then continue on to littler things.

So, what would you like to have documented?

The current list:

• Twig (you can find a spec sheet in /includes/class/Twig/spec.html to hold you over).
• The variables available to each theme file.
• A list of all required files for a theme and what they are responsible for.
• An overview of the theme structure (interaction between theme files), may fall under the above.
• A list of triggers, with descriptions. (an automated list, sans descriptions, can be found here)

I will add to this list based on comments received on this post (or anything else I think of).

New in b5: Improved route flexibility

Rather than using this blog solely for announcing new releases, I think I’ll start posting more details on new features and how the backend of Chyrp works as it evolves. So, we’ll start with a change to the “custom routes” system that I just pushed to the repository last night.

The “routes” setting is a humble little powerhouse residing in /includes/config.yaml.php that is shrouded in mystery to anyone who hasn’t used it when developing a Module. Its original purpose was to allow Modules to easily provide their own routes for when the user has clean URLs on. For example, the Tagginator module adds a tag/(name)/ route setting, which meant “when the visitor goes to /tag/foobar/ in their browser, set the Route->action to ‘tag’ and set $_GET['name'] to ‘foobar’”.

Here’s what it looked like:

routes:
  - tag/(name)/

This setting was managed by calling Route->add("tag/(name)/")¹, and Route->remove("tag/(name)") to remove it when uninstalling the module.

In beta 5, custom routes go one step further by allowing you to specify an action for any route. For example:

routes: # The beginning and trailing slashes are optional.
  tag/(name)/: tag
  unfinished: drafts

The first setting is the new form of the same setting from the Tagginator module in b4 and under. The second is a superfluous route I just threw in for an example. unfinished: drafts means “if they’re at /unfinished or /unfinished/, set the Route->action to ‘drafts’”. It essentially “clones” the /drafts/ page to /unfinished/.

If you wanted, you could view tags like /this-is-a-tag/ just by doing this²:

routes:
  (name): tag

There isn’t a risk of overriding other pages this way, as every custom route now calls an optional “check_route_[action]” trigger that checks if that Route should be used or not. In this case, a check_route_tag callback was added to the Tagginator module, so if there isn’t a tag at /(name)/ it will tell the Routes parser by returning false, and it will continue trying other routes instead. If there is a tag, it will return true, and the Routes parser will set the Route->action to ‘tag’ and $_GET['name'] to ‘this-is-a-tag’.

All of the examples above are only useful to those with “Clean URLs” enabled, but if you have .htaccess support and you have it disabled for some reason, you could just as easily do something like this:

routes:
  ?action=unfinished: drafts

If you’re a module developer, the only change you’ll have to make is adding a second argument to your Route->add function for the action the path points to.

2.0 beta 4 is out!

Chyrp v2.0 beta 4 is out, bringing us much closer to a quality, stable release. There are new technological improvements all over, and the server requirements have been reduced drastically.

See the README.markdown file for upgrading instructions, especially for you 1.x users. The upgrading method from 1.x is back to the original way of overwriting the old install and running the upgrader. Only, now we have an awesome task-based upgrader (see below) that supports all the way back to the first beta!

What’s new? Read More »

PDO Exclusivity No More!

I pushed a change tonight that makes the database backend even more flexible. You can now use Chyrp with either of the following (it checks in this order):

1. PDO (PDO_MYSQL or PDO_SQLITE[3])
2. MySQLi
3. MySQL
4. Coming soon: SQLite

This addition is still in testing phases (and the installer won’t let you install with the others yet), but it should solve a lot of problems with users on hosts that do not support PDO.