Re: api to get seo urls, plugins independent

[WP4J]

???Also there is a need to reverse decode links from content back to non-seo urls.

$app = JFactory::getApplication();
$menu = $app->getMenu();

print_r($menu->getActive());

Should give you everything you need in regards to queryvars and such.

On Sunday, May 5, 2013 6:39:02 PM UTC-3, jgo wrote:

does Joomla3 has standard api to access seo urls per item across different seo providers yet ? 

I can't find anything about in the docs. 

however, this is needed to build more complete web services for Joomla. 

Also there is a need to reverse decode links from content back to non-seo urls. It almost impossible to access the real urls without the help of the platform which dictate seo plugins to implement at least both ways.

thank you,

g

[jgo]

hi,

that assumes that the content is rendered with Joomla in a running browser. That doesn't allows me to reverse decode a link from an article on a low-level function which runs in background. 

So, in fact there is no way to properly encode/decode SEO urls through the platform API yet ? 

From a web-service perspective its pretty poor solved then. 

well, anyone else ?

[Bakual]

A webservice API is in the works. Because currently there is none.

Seo URLs are decoded within Joomla automatically and can be accessed using JInput.

[jgo]

Hi,

thank you. JInput doesn't seem to encode/decode urls when another SEO provider('plugin') is installed. So finally I am back to my original question, does Joomla respects 3th party SEO plugins and offers an interface to encode/decode urls from content or through webservices ? Because there isn't the smallest hint for that. 

 

Thank you,

I hope I can figure out an answer to this, since I am waiting since Mambo for a straight platform API in Joomla which does also guarantees a sort of data integrity across plugins, forth and back.

[piotr_cz]

Did't try, but maybe this will help you

$options = array('mode' => JROUTER_MODE_SEF);

$router = JFactory::getApplication()->getRouter('site', $options);
or
$router = JRouter::getInstance('site', $options);

// Encode (build route)
$route = $router->build($url = 'index.php?
option=com_content&view=article&id=1);

// Decode (parse route)
$variables = $router->parse($uri = 'content/articles/1:helloworld);

[jgo]

Hi,

thank you. But no, this doesn't work with SEF plugins like sef404 and others, for Joomla-Built-In-SEO yes but in the most cases people user plugins.

[Michael Babker]

Doing this would still require a massive update to our routing system and creating an interface that developers would implement.  At the soonest, we'd see that in 4.0, but the next question would be if developers would rewrite their code to use that interface.  We can't force them to do anything.

From: jgo <baumgart...@gmail.com>
Reply-To: <joomla-...@googlegroups.com>
Date: Saturday, May 11, 2013 11:22 AM
To: <joomla-...@googlegroups.com>
Subject: [jcms] Re: api to get seo urls, plugins independent

Dear Joomla-Devs , 

please make sure that content & data integrity is guaranteed. Please force SEO plugin providers to implement at least a few methods to make sure, that other plugin developers don't need to bloat their code. The worst part is actually, when uninstalling an SEO content goes corrupt too.

bad

[Gary Mort]

But that is the standard way to route urls, by using build and parse.  Moreover the API is there in 3.1[and I believe earlier] for SEF plugins to use.

Example:

$vars = array();

// Process the parsed variables based on custom defined rules

$vars = $this->_processParseRules($uri);

// Parse RAW URL

if ($this->_mode == JROUTER_MODE_RAW)

{

$vars += $this->_parseRawRoute($uri);

}

// Parse SEF URL

if ($this->_mode == JROUTER_MODE_SEF)

{

$vars += $this->_parseSefRoute($uri);

}

return array_merge($this->getVars(), $vars);

Notice that the FIRST function call there in parse is to _processParseRules AND that Joomla will only call it's internal parsing functions if the router mode is set to either JROUTER_MODE_RAW ot JROUTER_MODE_SEF

JRouter has publicly accesible methods for attachBuildRule and attachParseRule

An SEF plugin running early in the system process can:

1) Get the router

2) Change the mode ie: 

define JROUTER_MODE_SH404;

JRouter::getInstance()->setMode(JROUTER_MODE_SH404);

3) Register it's own parse and build callback functions in the router

That's it.  Done.  A new SEF system has now completely hijacked the routing system - and if it plays nice by adding a check for "if (JRouter::getInstance()->getMode() == JROUTER_MODE_SH404)" before it goes and does a parse or a build, then in the case of multiple SEF plugins being enabled you won't get complete destruction, but instead you will get a "last one wins" philosophy.

In short, the interface is already there, the API is already there.  It's up to SEF component writers to use it IF it is of value to them.

[jgo]

Hi,

Thank you, this looks a bit cleaner but still, it needs to know and cover MODE_SEF404. 

I'll check this out. Last time I saw SEF404's code, I was quite disappointed and I pretty much doubt this goes hand in hand nor ever will do.  

[Gary Mort]

On Wednesday, May 22, 2013 3:48:03 PM UTC-4, jgo wrote:

Hi,

Thank you, this looks a bit cleaner but still, it needs to know and cover MODE_SEF404. 

I would phrase it as  SEF404 needs to implement the hooks to know and cover MODE_SEF404.

I was merely pointing out that the initial request, for Joomla! to provide a standard set of functions to create and parse URI's has already been done - the API exists and is used today.

At this point, it is up to SEF extension developers to determine if they want to support it or not.  I think their only really likely to support it if there is a compelling use case made.  And part of a compelling use case is that people should be calling JRoute::_() in all their templates so that the hooks are already in place to link in everywhere.

[jgo]

great. the gui and editors are the next :-) , unfortunately not really good through ajax yet.

thanks again,

g

[elin]

Just to follow up on Gary, the truth is there are very standardized ways that routes are created in the core components (and a lot of copying and pasting in the various route helpers). Tags had to have a general way to make links to any content type for the tagged items view, so in writing it we started some abstraction of that in JHelperRoute and there is definitely more to be done there, but it does also provide some baseline guidance on what to expect from standard routing.

Elin