Another way to make navigation

by Jim Gay

John Long posted a great write-up of different ways to make navigation in Radiant. But there’s a certain way that I like to skin that cat which wasn’t covered: using <r:find>, <r:children:each> and <r:ifancestoror_self>.

See it at this gist

Permalink… Comments: 0

Non-standard extension locations in Radiant

by Jim Gay

Sometimes I’ll have the need to load extensions from a non-standard location.

I might have 2 instances of Radiant installed on the same server which may need similar but different functionality.

I can keep the code updated for both if I symlink their extension directories to “/var/radiant_extenions” for example, but then I’d need to mess with the environment files to specify the loading of extensions with config.extensions = [:this, :that, :the_other] in one and config.extensions = [:this, :that, :custom] in another if the requirements of the sites aren’t exactly the same.

Instead, if I know I’ll be just running “rake db:migrate:extensions” for the standard extensions I can place those in my shared location and symlink them as “vendor/standard_extensions” and put my site-specific extensions in “vendor/extensions”. To get that working all you need to do is add this to each environment and I’m good to go: config.extension_paths << "#{Rails.root}/vendor/standard_extensions"

Rake tasks won’t be loaded from there automatically though, so you’d need to be careful about what you put in your set of standards.

In the future, using extensions as gems will be nice, but creating a directory to manage standard extensions is helpful and just running “rake db:migrate:extensions” will load their migrations and bring them up to date in each database.

Permalink… Comments: 0

Code Spelunking: Radiant extension deactivate

by Jim Gay

A long time ago when Radiant was just a young CMS, it allowed you to activate and deactivate extensions with the click of a button.

This was simply an awesome feature. But there was a problem: it didn’t work.

Radiant couldn’t really know how you built your extension, and you can do whatever you want in there, so deactivating an extension might not actually deactivate certain parts. I’ve long wanted to take the time to look into Mixology to see how this extension deactivation feature might be able to make it back in, but the problem will still exist that you can build an extension however you want. Even if Mixology provides a way, it would only work with extensions built in a particular way; it can’t solve everything.

Even so, the feature was removed because: it doesn’t really matter, and nobody who worked on the core cared enough to put time in to solve a problem around what seemed to be an edge use case. How often do you need to turn off an extension, and does it really need to happen when the application is running? It would be nice, for example, to have a client upgrade or downgrade their account with the click of a button, which would remove or add features. I’m working on several ideas for this, but that’ll be a discussion for later.

So what’s with the deactivate method in your extensions?

It might as well look like this:

def deactivate
  # Ha ha! Fooled you!
end

Mostly, because of the generated code in many extensions you’ll just have something that says:

def deactivate
  admin.tabs.remove "My Extension"
end

That deactivate method is there because it was formerly used. It’s like finding a dinosaur bone in your back yard, but everyone has a dinosaur bone in their back yard so it’s not special.

Is this deactivate method ever used? Lets look:

The Radiant::ExtensionLoader has a method that looks like this:

def deactivate_extensions
  extensions.each &:deactivate
end

Clearly, this will call the deactivate method on each extension. And the Radiant::ExtensionLoader::DependenciesObserver has this method:

def before_clear(*args)
  ExtensionLoader.deactivate_extensions
end

Aha! So extensions are deactivated before they are cleared… And they are cleared… um… never? A new DependenciesObserver is created but where is the @observer object used?

This is where we start digging into Rails. Radiant bundles Rails, so we can stay within the source and find that action_controller/dispatcher.rb clears the dependencies. ActionController clears the dependencies and the instance of Radiant::ExtensionLoader::DependenciesObserver has the message before_clear sent to it, which calls each extension to run the deactivate method.

Does this mean that you can use the deactivate method in your extension? Yup. Put whatever you want in there. But still… it won’t do anything, or at least not much. Yes, the method is called (go ahead and drop a puts 'hello from the deactivate method' in there and watch your logs) but only in Rails development mode. In production, the dependencies are not cleared, your app just runs.

You can still use it, you could even build a controller for your extension to run the deactivate method and do something with it, but you’re on your own as far as the Radiant core is concerned.

So why keep that method in there at all? We even have specs built around it to ensure that it works properly. Sure, this means a bit of code complexity when the feature isn’t used, but it’s minimal and perhaps deactivate will come back in some way.

At a code sprint weekend over a year ago we discussed this method briefly and decided to leave it in because… well, maybe it will be of use in the future. I’m sure that it will be removed at some point if it is never used but for now keeping it in means that it can more easily come back and extensions using it will merely do things like remove some admin tab only to add it back in with the activate method and only in development mode.

If you’ve been wondering about that method, well, there you are.

Permalink… Comments: 1

Kicking the Gem Extension Tires

by Jim Gay

Josh French has been working on loading extensions in RadiantCMS as gems. I walked through the process and pushed out some changes to the Vapor extension to be loaded as a gem.

There’s currently no plan to cram this into the official release of the 0.9 version of Radiant, but I’d like to see it happen. I think that extension development and usage is a sticking point for the growth of Radiant and the community of extensions and developers.

Creating the gem was relatively easy using the jeweler and gemcutter gems, and then (after installing the radiant-vapor gem) I required it in my Radiant environment.rb with config.gem "radiant-vapor".

Radiant extensions (by default) have an update task which will copy public files to the project’s public directory such as images, stylesheets, and javascript files. The current downside of using extensions that are gems is that the rake tasks are not available from the extension. We’ll solve this problem in some way, but currently extensions such as Vapor won’t have much of a problem since there are no public files to worry about and even though this task won’t be found rake radiant:extensions:vapor:migrate, this one will rake db:migrate:extensions and will make the necessary changes to the database since the migrations are loaded.

Permalink… Comments: 2

More to come in Radiant

by Jim Gay

The next release of Radiant CMS will be a great one. The interface is definitely nicer and should make running multiple extensions much cleaner with the new navigation scheme.

One annoyance that’s been in it for a long time is the lack of a tag reference on the Snippet and Layout screens where they are arguably most needed. I hope to get an update for that in the next release. Radius tags on Pages should be discouraged, in my opinion, for the sake of the end user’s understanding of the system so it seems backwards that we’d have a reference on the Page edit screens and not in a place where it’s most needed.

If there’s something that you think is missing, or a bug that needs fixing, please go vote for it.

Permalink… Comments: 2

RedDot CMS is a POS

by Jim Gay

Quite possibly the worst experience I’ve had in working with a content management system is with RedDot CMS. I’m currently working with a client to update their site which is built in RedDot.

The manufacturer of RedDot claims to be “The Content Experts” but perhaps they exclude user experience from that.

I’m using RedDot, which is apparently old and has been replaced with an newer version with a new name. Hopefully they’ve updated everything about the user experience which is a mess of pop-up windows and cryptic ways to search for and link to images and content. One of the worst offenses, is that hitting the return key after entering text into a form to search for content for a link the page goes blank… Blank, because I hit return, and didn’t click on the custom search image button which is the only way it seems to submit the form.

An unofficial blog asks the question, “Is RedDot CMS Dead?”. Sadly, no. Even though it’s been replaced, there are probably many customers out there of RedDot resellers who must suffer it’s existence.

Being a developer and user of RadiantCMS makes me look at this from a particular perspective and will help me guide development of Radiant. With this experience, I’m officially picking a fight with other CMSes. I hope to learn a lot from other solutions and give my customers a better experience, but mostly I think its important to talk more about what is considered “enterprise” and show that the emperor has no clothes.

If you’re looking for a CMS, it should be easy to understand and easy to update. If you’re considering RedDot, or some vendor that provides it, think again for your own benefit.

Permalink… Comments: 7