A program fault has been recorded in the log
Home arrow Forum

Remository Forum



Karma: 0  
SEF advance extension tutorial? - 2005/12/07 01:17 Hi

this is probably in the wrong forum, but I thought it could probably get moved by a mod with a better idea wher to put it than me.

You guys have done such a great job with remosef..it works really well... so....

what I want to ask is...as you guys have done such a good job is it possible that you could share how to make a sef advance extension with us...There is very little help elsewhere....and sakics help file is explained for advanced (sic) users so I wouldnt know what to do to make an extension for a component (e.g. EZshop or simpleboard) i have tried copy various bits of code into a new sef_ext.php file but get nowhere fast

How about a tutorial on how to do it? ...pretty please

Thanks for the components and the good work
  | | Sorry, you do not currently have permission to write here.

Re:SEF advance extension tutorial? - 2005/12/07 14:27 OK, perhaps this will at least give you a start. There are really only two hard things about writing a sef_ext.php program to work with the interface established by SEF Advance and picked up by others, including ReMOSef. One is designing how your SEF URL is going to work at the same time as looking nice, the other is writing efficient code that takes account of the possibility that a large number of URLs may need to be processed for a single screen.

The basics are simple enough, the code must be contained in a class called sef_XXX where XXX is the component name (e.g. remository). There must be two methods - create and revert. Outside of the class you may want to include some defines or similar - personally I have kept any customisation variables in a separate file so that the actual sef_ext.php never needs to be changed by users.

The create method is passed the string that has been received from a sefRelToAbs call, so it should contain something like:


Since this is a standard internet query string, one route is to parse it with the standard PHP function parse_str(). But you can use other means to pull the string into pieces.

The next steps will depend on your design of how you can make a nice URL that will still tell the component all it needs to know. This may be quite complicated. For example, with Remository, the standard URL will identify a file simply by its ID, or a container likewise. The SEF version actually constructs a series of names to show the complete container hierarchy for a file or container. This is done using a memory version of the whole of the container information for reasons of efficiency.

A fall back option for less used options is the one used by the standard Mambo SEO - just convert the format of "name=value" to "name,value". All the previous stuff and this is done with forward slash as the separator rather than ampersand.

If you take the ReMOSef sef_ext.php as an example, all the methods apart from create and revert are specific to the Remository processing and do things like converting a container ID into a series of container names.

The second method that is required is revert. It is passed an array of strings and an integer offset into the array. The processing needs to start with with the array entry two higher than the passed offset (don't ask me why it was designed like that!). Already the component has been identified to know which sef_ext.php to call. So the first item you need to look at is likely to define what function to carry out. But this and everything else now depends on the design you have adopted for a SEF version of URLs used by the component you are writing for.

So, the passed array is really the SEF URL split at the forward slashes into its various components. What you have to do is to turn this back into a standard URL. Also, since a standard URL would have set variables in the PHP super globals $_REQUEST and $_GET you have to do the same. So anything that would have been like the parm=xyz example above has to be analysed and saved something like:

 $_REQUEST['parm'] = $_GET['parm'] = 'xyz';

The model provided with SEF Advance also indicates that globals with the same name should be set e.g. a global called $parm would be set with the value 'xyz' as well. This is what happens if the PHP option register_globals is switched on. However, it is thoroughly bad practice to write code these days that relies on these globals being set - components should specifically retrieve information from one of the super globals such as $_REQUEST. Mambo is moving towards totally blocking the setting of globals - this was the cause of the recent security exploit.

Once the whole array has been processed, you should have part of a conventional query string similar to the one given as an example above, and that should be the return value. You do not need to set option=com_xxx or Itemid as these will be handled by SEF Advance or whatever SEF component is in use.

That is it!

Copyright (c) Martin Brampton 2005 - may not be reproduced but may be linked to.
  | | Sorry, you do not currently have permission to write here.

Karma: 0  
Re:SEF advance extension tutorial? - 2005/12/07 18:55 Wooo hoo

Thanks very much for this Martin...

I'll have a go...

  | | Sorry, you do not currently have permission to write here.


Real Time Web Analytics