spiderglobe wrote:
Hi Amy,
I don't agree with you with the fact that I should use the SEF urls from the core. I do think that a custom extension is necessary for URL rewriting.
I think it's obvious we don't agree. I agree on that! ;)
spiderglobe wrote:
Why? Because for SEO purpose you want to define clean path's and clean filenames in the URL and you want to have full control over the URL's. The only way to achieve this is to make an URL rewriting plugin. In fact it's almost finished and I'm building the backend admin for the extension to manage the SEF urls. So we will release it. ;) under GPL but with a support model attached to it.
If you are only changing the plug, then I don't see an issue. You can make use of Johan's routing, then. Then, all extensions can be written to the core routing standard. Then, we don't create a situation like we have today where certain extensions work with certain SEF URL tools and not others. It's a mess and it's time it stops.
But, changing the plug is fine, in fact, the alias is how Johan allows that in articles and menu items. There's a bit more that can be done with some components, maybe? Fine, that could be a nice little plugin that doesn't impact third party extensions.
But, that's not what OpenSEF does today.
spiderglobe wrote:
Also the itemid issues is solved in the SEF url plugin and it's working great. For example I can now define paths like: /menu-alias/section-alias/category-alias/article-alias or any combination what you like to configure, for example /menu-alias/title-alias and this can (is not necessary) depend on the itemid.
This is what I would encourage discussion on. Your examples did NOT USE the SEF URLs. So, I want to hear what problem you are trying to solve with the core SEF URLs in place. I have found *one* problem with system-generated duplicate content and I reported it to see if it can be resolved. Instead of building another code base to solve the problems, why not work as a community? Johan's got this thing in good shape. I'd like to see the examples of duplicate content you are trying to solve WITH SEF URLs on.
RSS feeds - are great; Search results - great; Frontpage "read more" and title links - great; module links - great! I've been paying very close attention to this and I am not seeing a problem - with the exception of the one I reported.
I could be - and have been - and will be wrong - ;) - but, I sure would like to see some examples! And, if I'd like to see us work together to solve those in the core. 8)
spiderglobe wrote:
The reason why I'm building the SEF url plugin is that it is in my opinion necessary for good SEO, therefor the standard SEF system plugin (the default router) iis lacking some major functionalities.
I get the need for "good SEO" - but, I do not understand
what you see as specifically missing from the core SEF URLs. Let's not talk in generalities - let's use reproducible examples.
Again, your examples above were *not* SEF URLs - those were the
parameter URLs. Frankly, I'd recommend the core install default SEF URLs on so that people don't have to think about it at all. There is no reason to use the parameter URLs that I can think of. Johan has this working with Apache rewrite - with Apache rewrite you have added benefit of no /index.php/ - and now, drop dead sexy file extensions for .html and .pdf and yadda, yadda, yadda. You can use article and menu alias for your plug. What more would we want?
spiderglobe wrote:
In regards of performance it's also better to use the SEF extension we are building since once the URL's are created no more database lookups are necessary. The default router reads the MENU table's to fix the mentioned itemid issue. These are not cached but at each page request these queries are made. If you have a lot of menu elements this could be causing some performance / memory issues (I've seen some sites with a large number of menu items). The SEF extensions supports URL caching.
Richard - anyone who tries to work around the menu table is asking for trouble. Like it or not, the ItemID *is* the driving force inside of Joomla!. Having said that, if there are performance issues, let's see examples - get those reported - work on patches - get it into core. I am *not* seeing these performance issues nor am I seeing any reports of these problems on the forums and I am here A LOT!
Furthermore, I've seen a
great deal of work done in the performance caching area, so there are core options available - with lots of options - for performance gains.
spiderglobe wrote:
Another issue in regards of SEF urls is the support for legacy URL rewriting for the legacy components. This is done with the 1.0x sef_ext.php file in the components. This should be supported within the URL rewritting and I working on this as well.
URL re-writing for legacy URLs is a
different issue than SEF URLs for Joomla! v 1.5. It should not even be the same extension. There is a system plugin for redirects for v 1.0.x system SEF URLs right now. Some building on that concept as extensions are migrated will be important, certainly. I hope that is part of the migration plan extension providers consider as they get their extensions ready for v 1.5.
spiderglobe wrote:
The extension is combined with a plugin which 'replace' the main router functionality. This is really great in 1.5!
Wow. I would
not do that. And, I cannot imagine recommending anyone use a tool that would override Joomla! v 1.5's router, either. Why in the world would we want to do that to end users? That's the mess we are in today with these SEF URL tools. If you buy an extension for third party developer X, you are REQUIRED to purchase the SEF URL tool for third party developer Y.
Sticking to the core router means ALL extensions use the same approach and end users benefit.
spiderglobe wrote:
Also notice that I've been working to patch the 1.5 for SEO on the HTML creating part. Therefor I've contact Wilco / Johan and made patches but this is still not in the current 1.5 release due to the time frames to release 1.5 final, It will be l be on the roadmap for 1.6 >>
Charl is working on
semantic xHTML with the beginnings of improved microformats that can be used with some "fixing" now and will be available very soon after v 1.5 ships. I hope we see that in core for v 1.6. I'd be shocked if we didn't. That's what will help tons in SEO and I am rolling it into my v 1.5 sites now, many are.
spiderglobe wrote:
In my professional opinion 1.5 is a great CMS / application framework but still lacks good support for SEO which is necessary
- Good, meaningful URL's
- Good titles (which is not working well in 1.5)
- Good META titles support (full control over the html head section and to be able to define custom META fields)
- Good HTTP head support (full control over the http HEAD settings, but this is discussed before by Phil Taylor somewhere in the forums).
Regards,
Richard
I urge you to share *examples* of those things that you see as issues. It's time to work together as a community and build up the core functionality where we see it lacking. I am seeing very good things in this area. I am certainly willing to work with you to document the problems if you can show them to me. Walk my posts and you'll see - this is an area I've been focusing on with people. To this point, Richard, I have found ONE error and I reported it and linked to the report for you.
You will rarely see me this emphatic about not building an extension. URLs are core issues. It's time to think of the end user. Building SEF URL "correction" tools outside of core means not all extensions will be built that way. That hurts end users. FURTHERMORE and MOST IMPORTANTLY, reasons for SEF URLs in the past are gone. Johan has solved this problem in the core. If there are issues, we should get those issues reported, documented, and submit patches to get it in core.
With respect,
Amy
