After months (over a year?) of blood, sweat and the occasional tears (of joy), Chyrp v2.0 final is finally released. To commemorate such a huge release, we have a brand new site written entirely in Chyrp itself - it turns out Chyrp makes a fantastic general-purpose web framework. Huh. The Extend, Discuss, and Progress sections are just modules. Neat, eh?

I’d provide a changelog for this release but it would probably be long enough to fill your hard drive with your browser cache. So, head on Home and either try out a fresh-baked demo or head over to Download to grab it.

A big thank you to everyone who tested the release candidates, betas, and the git repository and reported bugs - this simply could not have happened without you guys.

If you’re not already there, chill out in #chyrp @ irc.freenode.net. All the cool kids are there.

P.S. No images are used on this site, not even the header. For some reason I’m especially proud of that.

If all goes to plan, Chyrp 2.0 as well as the new site will launch next month.

Version 2.0 is in its final stages, but I’m planning the release to coincide with a new site. When they’re both done they’ll both be released to the masses.

If you’re impatient, feel free to just use the current git repository. Once the site is done that’s where the release will come from, and it’s generally more stable than official releases anyway. It’s not as glamorous as a big pretty 2.0 stamp but it works.

The third release candidate for v2.0 is out. Download here. As usual, read the README for upgrading instructions if you don’t know them already. (tl;dr: disable modules, overwrite junk, run upgrade.php, enable modules, run upgrade.php again.)

What’s new?

• Stronger Model backend. Implemented has_many, belongs_to, and has_one relations between models. This is done using the magic get PHP method. So, for example, $visitor->group()->name is now $visitor->group->name. The previous method is maintained for backwards compatibility, but will be removed after 2.0 goes final.

• Added a paginate Twig block syntax, for paginating over arrays or arrays of placeholder‘d Models.

  Usage:

  {% paginate loopvar in perpage source as targarvar %}
  $loopvar.title
  {% endpaginate %}

  • loopvar is the variable used within the paginate loop.
  • perpage is how many per page.
  • source is the source array.
  • targetvar is the var to set in the main scope, e.g. $targetvar.next_link
• Enhanced keyword searching:
  • Searching post attributes, e.g. name:Google for searching for a link named “Google”
  • Multi-word searches, e.g. source:"Albert Einstein"
• Rewrote the Tagginator module to use the post_attributes table and YAML.
  • You can also view posts by multiple tags, e.g. http://example.com/tag/tag1+tag2+tag3/.
• Comments module now uses the has_many Model relationship with Post.
• Added a list_notate function that turns an array into "foo", "bar", and "baz".
• Replaced our truncate function with the one from CakePHP, which auto-closes HTML tags. Woo!
• Added standard markup_title and markup_text filters.
• Added an extensible email function that serves as a mail fallback.
• Added a now helper that acts as a mask to strtotime, for hotness like now("+1 day").
• Added a relative_time helper, for things like 10 hours ago. Goes up to millenia. Just in case.

There were also a lot of fixes in this release. I’m not going to list those though, for the sake of my sanity and time. If something was broken for you before and it works now, well, there you go.

I broke my promise of not adding things in this RC again, but as they’re all completely backwards-compatible, I hope you can forgive me. :)

With this RC everything on my to-do list and every Lighthouse ticket is now closed. As such, this should be a much more traditional RC in that no more major features will be added. I’m now working on the new site.

The second release candidate of Chyrp v2.0 is out now.

A crapton of things have changed between RC1 and now, which technically shouldn’t have been done since it was an RC, but I felt they needed to be addressed and fixed before 2.0 was out. I believe the backend has improved 20-fold. See the README.markdown file for information on upgrading. Users of RC1 will have to run the upgrader as well.

What’s new?

1. A stronger Route <=> Controller <=> View relationship model.
2. A smarter Route system of determining which route should be used. Controller callbacks return false if they result in failure and should be chosen at a low priority, allowing the next action to be attempted. The first one that doesn’t return false or the last one attempted will be chosen.
3. Post attributes and group permissions no longer store XML and YAML in the database.
   • Group permissions are stored in the “permissions” table, which has been modified to add a group_id column. Stock permissions are stored with a group_id of 0.
   • Post attributes are now stored in a post_attributes table and grabbed via a SQL LEFT JOIN. This makes searching for posts much more accurate, and means no XML needs to be parsed. Modules/Feathers that store nested post attributes are encouraged to store them as YAML and parse them at the filter_post filter.
4. Group-specific post statuses.

More Information

A full log of changes can be found at the 2.0 RC2 commit log.

What’s next?

If no bugs are reported after this point, 2.0 RC2 will be repackaged as v2.0 final. There should not be any more radical changes after this.

Enjoy!

Update: I went with solution #2, removing the feature entirely. See below for a workaround if you want to still use this feature.

…As it is right now, anyway. Maybe. It all depends on how this post is received and the response to it.

The problems:

1. The feather viewing route is the single oddball route (excluding post/page viewing). Instead of a simpler /feather/quote¹, it’s /quotes. Same goes for /?action=quotes. It seems weird to have such a special spot reserved for such a minor feature.
2. It takes a special case to tell what we’re trying to do, because the action itself (the first thing after the / in the URL, e.g. /foo) is never the same.
3. In order for this feature to work, every Feather’s info.yaml file must be parsed on every page load, so that feathers can provide custom plural forms (you wouldn’t want /texts for the “Text” feather). This increases the page load time.

Viewing all of the posts of a feather seems like a very edge case when you consider that we’re lowering the quality of the entire application for it.

The solutions:

1. Change from /quotes to /feather/quote (/?action=feather&name=quote with dirty URLs).

   If you’re currently using the /quotes route exclusively and want to keep it, you could still do it rather easily with custom routes:

   # ...
   routes:
     quotes: feather;name=quote
   

2. Remove it entirely, and have it added via a custom route:

   # ...
   routes:
     quotes: search;query=feather:quote
   

Thoughts?

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 »

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

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.

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 »

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.

At the risk of ripping a hole in the space-time continuum by going into decimal places for a beta number, beta version 3.1 is out. It’s a minor release that, uh, makes the installer not break.

Grab it here.

And this time I have a proper changelog (after the jump). :P

Grab it here.

There should be no upgrade process for those upgrading from older 2.0 betas, aside from overwriting all your files and setting your timezone.

A few more bugs were found after the 2.0 release, and I didn’t want to keep “quietly updating” the 2.0 beta 1 file, so 2.0 beta 2’s here. A whopping two hours after initial release. :P

There are no database changes in 2.0 beta 2, just overwrite your old files with the new. Also, one thing was left out of the 1.1.x → 2.0 upgrader accidentally - you’ll want to rename your “rss_posts” setting to “feed_items” in your config file (or just set it in Admin).

Fixed:

• XML-RPC
• Extend → Themes warnings
• Upgrader now sets Config::$feed_items

Also, tip: /rss is now /feed (2.0 uses Atom, using “rss” as the URL makes no sense), everywhere, so if you use FeedBurner you’ll want to update it.

If you installed Chyrp 2.0 and were greeted with some ugly errors under Extend → Themes in the Admin area, re-download and replace your /includes/controllers/Admin.php with the one in the archive. Sorry.

Also, I’ve fixed the Tags & Comments module upgraders, so do the same for them with their /upgrade/1.x_2.0.php files.