Symphony.

Hi fellow extension developers and users,

It just occurred to me that I was aware of at least one extension, namely the JIT image manipulator, that modifies the htaccess file.

Recently there have been a few posts, including some of mine, relating to the use of non-apache web servers so I thought it my duty to bring it to the attention of any extension developers that the htaccess file is (to the best of my knowledge) an apache-specific tool and is NOT compatible with many (if not most) other web servers. Servers such as Lighttpd and Nginx are growing in popularity, even if they only represent a fraction of usage at present.

I am aware that apache is still by far the leading server used worldwide based on stats I have seen, but I feel that it is important that developers are aware that non-apache symphony users exist.

More broadly speaking, extensions that modify non-symphony files could cause problems in migration to other platforms or hosts.

Of course this is all open to debate, but I thought I ought to get the ball rolling if it isn’t already in motion.

Good point. One-time alterations could be done manually, if properly documented. But there are alse extension that dynamically modify the htaccess file;

The language redirect extensions adds iso language code to a rule as you ad languages to the preferences. I had discussed with the author to keep the rule abstract though…

THe URL router extension that I wrote uses the FrontendPrePageResolve delegate to pick up the URL and manipulate it, and this could certainly be used for things like the JIT image manipulator as it could catch any URL beginning /image and then do it’s own thing.

I’m not suggesting that every possible angle can be covered this way, just that the more extensions that are self-contained, the better.

Food for thought anyway.

I’m not suggesting that every possible angle can be covered this way, just that the more extensions that are self-contained, the better.

Particularly with JIT I think it’s important that these are retained in .htaccess for performance reasons. Using delegates is fine, but it requires the Symphony object to be instantiated and a series of database calls to be made. Using hard Rewrite rules prevents this.

I suggested to the team the other day that Symphony 3 provides an API for modifying the .htaccess file: there is presently an API for persisting values to the config.php file, so this could be expanded to storing Rewrite rules (or similar) to .htaccess.

Keeping .htaccess rules compatible with Lighttpd and Nginx is going to be as hard as writing SQL that works across MySQL, SQL Server and Postgres; without some form of abstraction…

The biggest problem I see is the skip rule as it’s dependent on the number of rules after it.

I’d like the idea of a class all extensions can register their rules with. This class will then manage dependencies and create the file.

This can, of course, only be a long-term goal as it’s gonna take a lot of planning…

An interim solution could be a checkbox/selectbox in System->Preferences to activate modification of the .htaccess file.

What happens when you install an extension that modifies the .htaccess rules on systems that don’t support it?

I’d like the idea of a class all extensions can register their rules with. This class will then manage dependencies and create the file.

Interesting. I will give it a go tomorrow (unless somebody from the core is already working on this?)

@creativedutchmen: The team isn’t currently looking at this, we would greatly appreciate some assistance on this :)

What happens when you install an extension that modifies the .htaccess rules on systems that don’t support it?

More than likely, nothing will happen (or there will be an error) and the extension won’t work.

I was discussing this with my colleague Nick Dunn yesterday. I was arguing that it shouldn’t be necessary to have to use Apache, and he was arguing that you can’t support every server setup and that a common platform requirement gives devs something to work against.

I don’t disagree with his point, but I think it’s an unecessary restriction and that there must be a way to handle URL manipulation (e.g. rewrites) internal to symphony.

Of course the issue remains that there needs to be a basic set of rewrites at the server level to make the system work, direct all requests through a front loader etc, but once these are out of the way, everything else could be handled internally.

Nick also argued that, if a developer like myself has the knowledge to get symphony running on nginx then I’d be fine sorting out any extensions (which is true), but my counter-argument is simply that extensions should be self-contained if they can be, and a URL handling mechanism that is internal to symphony would help with this.

All the rewrites definitely need doing at a server level, like stated before, for performance reasons, but I also agree that a layer of abstraction in Symphony that would apply the correct rule typing to the correct server type (maybe chosen at install) is a really great idea.

As Symphony grows, I believe that the more abstraction that gets built in the better, this gives users the chance to use thier prefered system without having to hack anything, and as there are already developers who use these setups, it can be done without too much difficulty.