Add ability to specify custom mount url for admin back-end

[andrewhavens]

We now have the ability to mount the entire Refinery engine at a custom subdirectory:

mount Refinery::Core::Engine, :at => '/subdirectory'

However, this affects both the front-end and back-end. If you wanted to access the front-end at / but the back-end at /admin_panel, there's currently no way to do this. I think it would be a useful and important feature to be able to specify the Refinery back-end url, either from a config file, or in the routes.rb file. Maybe something like this:

mount Refinery::Frontend, :at => '/'
mount Refinery::Backend, :at => '/admin_panel'

I think this is even more important for non-english speaking users. /refinery might be ok for english speaking users, but I doubt that it's easy to remember for non-english speakers.

[phiggins]

👍

IMHO, "/refinery" is an implementation detail the user shouldn't have to care about.

[phiggins]

In discussing this with @parndt, we identified 3 possible ways of supporting this in refinery, in descending order of preference:

1. Add configuration options in Refinery::Core that are referenced in the routes.

This is the approach taken in this pull request to refinerycms-blog, which we (@parndt, @ugisozols, and myself) all agreed was not the best approach.

2. Split the refinery engine into two pieces for the frontend and backend to allow specifying two mount points.

Using something like the following:

mount Refinery::Core::Engine, :at => "/my_custom_path"

... allows customizing the admin path but will also change the user facing path. This means all of your pages would have paths like "/my_custom_path/home" instead of "/home". To avoid this, refinery could be split into two engines and then mounted like this:

mount Refinery::Core::Engines::Content, :at => "/"
mount Refinery::Core::Engines::Admin, :at => "/my_admin_lol"

This might work, but would require a significant refactoring of refinery to support isolating the two engines from each other, and might introduce unforeseen complications that make working with refinery more painful than it is now.

3. Add a method that the user calls in their routes file that defines refinery's routes.

Similar to how Devise has devise_for methods to define its routes. This would enable the user to do something like the following:

refinerize! :admin_path => "/my_custom_admin_lol"

(Note: I made the name intentionally stupid to make an effective placeholder.)

Pros:

• Allows customizing the admin path (the subject of this ticket).
• Allows further customizing of other things we're not talking about: the path to user-facing pages, etc.
• Some smarts could be added where if refinery is not mounted after the user's routes have been defined, it mounts itself with the default parameters. This would make it so requiring refinery was all that was necessary to have the refinery routes defined.

Cons:

• There might not be an interface for doing this sort of stuff in rails, and so would require monkeypatching that potentially breaks on a rails upgrade, etc.
• It is non-standard and therefore will probably cause confusion and concern over unnecessary complexity ("why use this instead of 'mount Refinery::Blah'", etc).

---

What do you guys think?

[ugisozols]

I remember I was having an idea for dual engine like Refinery::BlaBla and Refinery::BlaBla::Admin but I can't remember what was the issue and why did I discarded it. I'll have to play with it again in order to remember.

[andrewhavens]

Personally, I like the devise_for / refinerize approach. It abstracts it enough that it doesn't feel awkward, provides a simple interface for setting these (and future) settings, and keeps the routing settings in the routes file where it belongs. I think the non-standard method call is an advantage because it doesn't set any expectations (or requirements) of how it's supposed to work. I also like what you said about providing some defaults, so refinerize might only be used if you wanted to override the defaults. Otherwise Refinery CMS would be mounted at the normal path of /. So you could name it something like

override_refinery :admin_path => '/custom_path'

[ugisozols]

I like @andrewhavens proposal:

mount Refinery::Frontend::Engine, :at => '/'
mount Refinery::Backend::Engine, :at => '/admin_panel'

So we would have to add two small engines for backend and frontend and add routes inside these engines. After that we should change refinery helper to refinery_frontend and refinery_backend accordingly.

Sounds like a plan?

[simi]

@ugisozols I'm +1 for this approach. If you can point me to start, I have time to do this.

[robyurkowski]

I'm torn. On one hand, I rather like the flexibility offered by mounting two separate engines, but on the other hand, this adds a layer of complexity to engine development and to mounting. It's also going to mean we're going to have non-standard installs all over the place, and we're going to have to keep that in mind when troubleshooting.

On the other hand, I hate the Devise-like approach because it is so opaque. Powerful, yes, but very opaque.

Tertiarily, I kind of like the separate mountable engines idea purely for the thought that it might lead someday to the creation of Refinery-backended web services.

👍 to Frontend/backend engines.

[parndt]

I don't like the added complexity that this requires. I don't want to write code like this:

link_to "ugliness", refinery_backend.admin_pages_path

And this

link_to "moar ugliness", refinery_frontend.pages_path

/me shrugs

[ugisozols]

I haven't experimented with this but what if we could use two engines Refinery::Frontend and Refinery::Backend which both would respond to refinery helper? @parndt that's what you asked in the beginning ;)

It's late for me so I'll stop here and will play around with the above tomorrow (if someone won't beat me already).

[parndt]

That would be amazingly ideal, @ugisozols

[phiggins]

@ugisozols: That would make the seperate engine implementation a lot nicer. I vote for solution #3, but I can tell that's not a popular opinion. ;)

[parndt]

I agree with @phiggins who inadvertently referenced issue 3 just now.

[ugisozols]

I tried two engines (Refinery::Frontend and Refinery::Backend) with the same name (engine_name :refinery) but unfortunately we can't use that approach because we can access only routes from the engine which gets mounted last.

[robyurkowski]

As per discussion with @parndt, we'll be saving this for 2.1.

[robyurkowski]

So, let's come back to this: can we do this / do we want to do this for 2.1?

This is actually a really big change, and could very well break compatibility — I'm tempted to leave this until Refinery 3... thoughts?

[andrewhavens]

I think this is a really important feature. I wish it could have made it into 2.0. Version 3.0 seems so far away, but maybe it's not?

[ugisozols]

I'll revisit this soon.

[robyurkowski]

I'm going to close this, and move this to the Roadmap for the unspecified issue. Nobody seems to have time to do this now, and though we're all in agreement, barring an implementer, this is a non-starter and its presence here is obscuring the other more accomplishable issues.

If anyone disagrees and thinks that this is critical for 2.1 or 2.2, feel free to reopen.