Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Allow the backend URL to be changed #702

brendo opened this Issue · 30 comments

10 participants


By default, Symphony is fixed to /symphony. It comes up from time to time where users would like to change this for whatever reason. In 2.2 a new constant, SYMPHONY_URL was introduced, and slowly the backend has been making the transition for all hardcoded /symphony to use the constant.

While perhaps not on the immediate cards for 2.3, some publicity needs to be raised about the SYMPHONY_URL constant, so extension developers can start to use this as well.

A future version of Symphony, perhaps a 2.3.x release, will allow users to select their own backend path at installation/via the config.


I like this. It's a small thing but some clients have already emailed me again: "What was that login path again?" :/
Being able to set it to /cms or /admin e.t.m. would be nice.

So, this is already possible by setting the SYMPHONY_URL in the config (and apart from the fact that extensions might have hardcoded the /symphony url)?


In theory yep. The .htaccess would need to be adjusted as well


I've been thinking about that lately. Stop me if I'm going off-topic, but wouldn't URL-routing be a nice feature here? Currently all the routing is hard-coded in the .htaccess-file. Even extensions like JIT or Language Redirect add rules to the .htaccess file to change the rules.

I've been following a course in Magento lately, and a nice concept they use where in my opinion were URL routers. Basicly all requests went to index.php, and according to some routing rules in the database, Magento decided what to do. Something like this could be easily implemented in Symphony and would provide great functionality for future extensions.

A basic approach would be to create a database table (or store it in your configuration) with specific regular expressions that fire callback-functions in extensions. You could also add a loading order to this. For example:

  1. Regexp that matches if the URL Request starts with /image/ (JIT extension does it's magic)
  2. Regexp that matches if the URL starts with /symphony/ (Symphony launches Administration::instance()->display(getCurrentPage());)
  3. Regexp that matches if the URL starts with /en/ (Language redirect does it's magic)
  4. Regexp that matches if the URL starts with /nl/ (Language redirect once again...)
  5. Launch Frontend::instance()->display(getCurrentPage()); (default behavior)

I really think something like this could be easily added in the current scope of Symphony, and would provide a more solid solution of URL routing and providing extra functionality for future developers. Think of it, how easy would it be with an approach like this to create a marketing-flashy SEO URL like which actually shows

Once again, didn't mean to go off-topic here, but it's just an idea I see great potential in.


The functionality you describe is exactly what the URL Router extension does :)

This issue is more so people can rename their Symphony directory for security or whatever purposes.


lol! Didn't know about that one! :-P

So... wouldn't it make more sense then to move the routing logic out of the .htaccess-file and into something like this (whether it should be core or functionality or not)? Keeps the .htaccess nice and tidy i.m.o.


Not really. Having routing URL's in the .htaccess file will always be faster and more powerful than a PHP implemented solution.


True, it's just that I'm always a bit nervous when extensions start modifying actual files, like some extensions do. But if that's the convention the Symphony community is willing to live by...


Can't you just update SYMPHONY_URL and the appropriate RewriteRules? No need to muck with changing the actual directory if you let mod_rewrite do the heavy listing.

Assuming you convince extension developers to stop hard-coding, of course.


Given that most extensions will be updated for 2.3, what do we need to do to make sure this is easily done in 2.4? Use SYMPHONY_URL in PHP and what in JavaScript? We could include this in developer migration notes for 2.3 so devs can prepare now...


Correct. It was mentioned in the 2.2 notes but I can mention it again.

@brendo brendo referenced this issue

404 error #1297


Can I make a suggestion regarding this?

Could we implement this using Apache's SetEnv in the htaccess file? I've been doing some reading about this, and it would seem to be the only way to allow the constant to be available in the htaccess as well as PHP.

If everyone is ok about this, I'll do the work and test the change too.


I've been looking into this today, regarding my suggestion, and it seems it's not as easy as that.

The reason I suggested it is to make the change very easy for people installing the system to do, so we could have it as an option in the installer. Setting the SYMPHONY_URL constant in the htaccess means that it can be done via the installer, and then be a very easily changeable option if the client decides to do that during development. The only problem arises when trying to match a URL to that constant.

I went down the route of setting an intermediary environment variable SYMPHONY_PATH as symphony by default, and in the defines.php file, I did a check for that env var and defined the SYMPHONY_URL based on it's content. That was all the easy bit done.

The problem arises when using the current setup of redirecting in the htaccess file based on the existence of symphony in the URL. If we want to go down the route of making this properly configurable while removing the problem of having to change this word in more than one place, I think that we need to re-address the way we set the mode (administration, frontend) for Symphony.

While I am a big advocate of doing the redirecting in htaccess over php, it makes sense to move this tiny fragment of the process into the index.php file for this one thing. Extensions that need redirects like JIT and the REST API should remain in the htaccess file.

I will make the change and let @brendo look over the code.

@designermonkey designermonkey referenced this issue from a commit in designermonkey/symphony-2
John Porter Add new constant/env var for issue #702
This adds a new constant and environment variable allowing the developer to specify what URL Symphony admin lives under

Also, could we change the milestone on this one to 2.3.1 as I've changed the updater for 2.3.1 to add this feature.


Also, I've already fleshed out an extension to allow the admin to change this from within Symphony Preferences.


Would it be sane to make this configurable during Symphony installation?

If @designermonkey's extension (where can someone find that ?) works as advertised I vote for integrating it within symphony.


I have already integrated this with the installer and updater in my pull request.

I was chatting with @brendo t'other day about this, and he wants to do some thinking about how this would work with other http servers. We currently support Apache2, but users are often setting Symphony up on other servers like nginx. I know David Oliver uses another one.

If anyone has any experience with these servers, can they speak up about whether these changes would be workable in their systems.


If multiple servers need to supported then this should be handled from within PHP as @kanduvisla was saying. It is the simplest and most manageable solution.


@designermonkey, concerning setting an environment variable using the webserver's rewrite rules (I think this is what your approach relies on?), I don't think this can be done in Hiawatha. Its URL toolkit doesn't have any environment variable-related commands.

Hiawatha allows for environment variables to be set in the vhost config, but this would obviously be down to the user/server admin and so I think it couldn't be handled directly by Symphony at installation/in preferences.

A quick search at nginx's HttpRewriteModule also suggests it doesn't allow for environment variables to be set there.

It also seems to be the case that some users may not have permission to use SetEnv in Apache, which could stop this approach to setting a custom admin URL working for shared hosting users, for example.

More generally (environment variables as well as other URL rewriting), if Symphony is not going to limit itself to Apache (and I really don't think it should - it works beautifully with Hiawatha straight out of the box apart from the Apache-only rewrite rules which need their URL toolkit equivalents adding, and I know nginx is very popular), based on my very limited knowledge I think I agree with @kanduvisla and @petsagouris.

Relying on one particular webserver's URL rewrite mechanism for much else than sending query strings to index.php does seem a quick and dirty route in comparison to a more webserver-agnostic approach, and results in every webserver needing its own set of rewrite rules, both for the core and any other current/future extensions. The Hiawatha documentation includes a collection of UrlToolkits for applications, and you can see Symphony is already one of the longest.


I've been following a course in Magento lately, and a nice concept they use where in my opinion were URL routers. Basicly all requests went to index.php, and according to some routing rules in the database, Magento decided what to do.

This kind of approach (doing what the URL Router extension does?) sounds great to me.

Another consideration might be that some server admins don't allow .htaccess files. If they are enabled, the webserver has to scan every directory for them, and so some people make sure they turn it off and instead configure their rewrite rules via config files. Personally, I know one Apache server admin like this. From the Apache manual:

You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance.

Anyone's free to configure their Apache webserver accordingly, of course, and it's their responsibility, but maybe it's one more little reason to consider moving towards an in-built approach to URL rewriting.

Related: I've been discussing using and supporting Symphony and other applications I've installed on my webserver at the Hiawatha forum, and the main author of that webserver has some (strong?) opinions on URL rewriting. From the Symphony REST API extension URL rewrite conversion and URL rewriting for LemonStand threads:

Well designed frameworks and CMS-es rewrite requests for non-existing files to index.php and handle those requests themselves. Maybe some extra rules to improve user experience, but basicly you can say that everything more than that is a sign of bad program design.

No offence, but LemonStand has a serious design issue. No CMS / framework should ever require a weird and complex URL rewrite like this.


@DavidOliver thanks for your input there.

I can see the issue from both sides here, and also, I can agree with it on both sides too. I am currently chatting to Brendan about ideas.

Will posts more later.

@designermonkey designermonkey referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.

I've started to look into this again, and I think we have a bit of a problem.

In trying to decouple the URL rewriting from htaccess and into the index.php file to pave the way for other http servers, I've realised that because we have a physical folder called symphony we have an issue moving forward. To take the rules for frontend vs administration and move them into the index.php file, we have to allow all paths through the htaccess. The problem therefore is that we ignore all paths that resolve to a physical folder or file, to allow css and js etc on the frontend. Because of our application being housed on a folder of the same name as our default admin URL, we can't rewrite symphony without the administration rules.

This includes my previous idea to fix this, which is also majorly flawed because of this.

The only real solution to move this issue forward os to rename the symphony application folder to something else. That being said, if a developer decides to name their admin URL the same as a folder, we will be back at this issue again.

This is a lot more complicated than we first thought. Damn rewrites :(


Why not just renaming the symphony application folder to core and prevent developers from using core as their backend handle (should be a setting on the preferences screen anyway)?

Also worth mentioning, if I create a frontend page called symphony, extensions, workspace, manifest, etc. right now, the page isn't accessible, so page handles should be checked against this new setting and other preserved application terms as well.

Other simple solutions:

  • Using a prefix for application folders, like sym_extensions, sym_core, etc.
  • Putting application folders into a "namespace"-folder called application or something, then check the backend handle and page handles only against that term.

I like the idea of that. Also, it makes me realise why it's a good idea that @brendo wanted to move the folder structure around.

Having a core folder for the application, and one for the workspace would definitely make sense in this scenario. I think we need to expand this issue some more and open it up for more discussion.

Related issues:


Bish, bash bosh. Done.

Going to leave the HTTP server logic alone in this issue and do that another time. Admin URL changing will soon be possible in 2.4

Happy face: :D


Nice job :)


Thanks dude. I have more up my sleeve ;)


#1547 seems to take care of this issue.
Can this discussion be closed?


Not until it's pulled in. There may be issues with it as it was done a while back.


But your pull request is listed as normal issue in the list.
Shouldn't the discussion continue on the pull request?
This discussion is referenced in the pull request somehow or other.

(I'm just trying to clean up this tracker a bit.)


I've always wondered at the logic of displaying pull requests in the issue tracker, but thats up to Github.

If you want to close it and reference it in the PR, then OK, we haven't done it that way before, but I see your point. We have a lot of issues.


Yeah, it's a bit strange because pull requests also have their own tab.

In order to minimise duplicates on the tracker, I'm closing this discussion. Let's continue on #1547.

@brendo brendo reopened this
@brendo brendo closed this
@brendo brendo referenced this issue

Prepare 2.4 #1892

8 of 8 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.