Joomla! Discussion Forums

This may seem like a random, dumb idea, but what has Emir got to loose by integrating something like OpenSEF, or any of the other GPL SEF products now ?

That way, everyone who wants a better open source SEF solution gets it..

Delaying a better SEF solution until J! 2.0 only leaves people asking.. and because there are better open source solutions out there currently than what is integrated in J! 1.0 / 4.5.2, the codebase is already there..

Emir, why don't you give the community a good reason why the current SEF solution in J! is appropriate and shouldn't be updated (even at 1.0.1 update) for a better one ?

(I custom hacked the SEF solution I run on my site because the solution that Emir built for the 4.5.x brand didn't do it's job)

Glad to see some discussion here; I made a few posts in a mamboserver forum about duplicate URLs for same content.

I'd like to see Mambo generate Cool, SEF links.
Cool links as per W3C - ie once you have a link to a page of content, you can keep it, even if and when upgrade software etc.
SEF - easy to read by search engines. I don't think this is real crucial - I have forum threads that do ok in google with "raw" cms type URLs; but can only help, esp if include a keyword or two.
Plus, also importantly I think, good SEF URLs are more human friendly - maybe better for people to click on, and for cutting and pasting (working better in emails, where long URLs that split onto two lines don't always link well).
And, can end in .html - which I read somewhere might put people looking to do bad things to php sites off the scent.

Tried 404SEF, but had problem others had (and author noticed) - kept slapping id numbers on end, so could wind up with a bunch of URLs pointing to a page. This is a Mambo issue, I think introduced after 4.5.0 - and making Mambo URLs less "friendly" than before.

I use beta 2 of Xaneon, and impressed by it; was real disappointed development stalled, think it's great that development is back on track - glad to see Ken's energy in helping get things moving; fingers crossed.

I don't have too many glitches w Xaneon - maybe as not enough hits to wallop the database; would like to see its abilities extend to URLs for components (such as forum, menalto Gallery [there's fix for Gallery 1.5 and Xaneon, but a bit complex to me]).

Like the name OpenSEF.
After some more development, maybe it can be included in Joomla! core - as an option. ("SEF" is option now; could have additional OpenSEF option, with proviso it might not work perfectly. [won't be quite the only such thing in Joomla! core after all; but then, this is open source and occasional hiccoughs to be expected.])
Pro users who require support could then opt for SEF Advance. Dunno if this may work.

Then, on to a few other things.
One being page titles (in head code) - way more important for search engine rankings I believe. Good progress so far; but also making things easier for extra components would be good. (Latest simpleboard generates titles for threads; but for Gallery I've so far only managed album titles - photo titles would be great [my php hacking efforts not up to this so far, plus have hopes re G2])

Since this topic seems to have recieved so much attention and poor Emir seems to receiving unneccessary flak for some reason I will answer.

======================================

Will SEF Urls help with SEO, probably, how much is open to debate.
SEO is more than just SEF Urls, if it was that simple than every site would be clamouring for it.
SEO is a combination of many factors.

Any implementation of SEF will necessarily lead to a performance hit, as it will mean additional query(s) to determine the url to rewrite.

======================================

Secondly its matter of priority, only so many man hours, so things must be prioritized.
To increase the priority of one objective comes at the price of something else on the list.

For example Absalom, you know we have certain objectives regarding tableless output and core code.  If for example I look into this issue, than I may not be able to work as much on the issue of tableless core output.

You cant hit all objectives in one go, thats unrealistic, you have to prioritize.
And simply adding more core developers doesnt solve the issue, because at a certain point, adding more members to the team leads to dminishing returns and less efficiency.
Any organization has an optimal number of workers (determined by factors like management structures, communications structures, infrastructure).  Throwing more people at a problem doesnt solve a problem and often just leads to a loss of operational efficiency and organizational problems.

======================================

And it simply is not just a matter of pulling an existing 3rd party addon and plugging it directly into the core.  No matter how well somethgin like that might be crafted, it would need to be examined and fine tuned or even rewritten to be included - this takes time and manpower.
Being in the core, has advantages not open to Addons so code always gets rewritten, even for the excellent solutions that were initally addons to core - which I have done on more than one occasion for excellent soutions created by community members.

======================================

In terms of when such an issue could be revisted, Emir states that 2.0 is the best place to build a totally robust system.
And I agree as there are far more important architectural issues regarding urls created by Joomla, than simply SEF and this is the problems with the Itemid, which cannot be fixed short of a total overhaul, as the whole Core system is dependent on it.
And SEF wont solve this, as the system reads the non-sef version for operating (IE sef gets converted to non-sef) where the Itemid problem still exists.

We cant look at it for 1.0.x as the .x refers to maintenance releases which are bug fixes only and no new features.

We cant look at it in 1.1 as we already have objectives to complete for that.

However, beyond that, we may be able to look at the issue for 1.2 or beyond and craft a `solution` for this with the Joomla 1.x series.  And I have been considering a possible way to add to improve functionality, but this will take time to plan, test and implment.

SEO
The ongoing discussion regarding SEF URLs helping or not helping SEO is only part of the issue.
Frankly the debate is silly.
OpenSEF probably should have been called OpenURL.
Xaneon Extensions was called that instead of something like Xaneon Advanced SEF because of all the different uses or extensions that it provides.

Re-writing URLs is useful for many other reasons:

• maintaining incoming links - take users directly to the new page
• usability - provide users insight to the web site structure
• usability - provide easily typed links
• deliver multiple URLs from one back-end
• deliver multi-language from one back-end
• disguise your DB structure
• and on and on and on . . . all the reasons people use mod_rewrite

Performance
Use of any component may have a performance impact.
The decision is up to the user to use or not use OpenSEF or SEF Advance, or anything else.
There are web sites running XE2/OpenSEF with thousands of URLs.
I am sure the situation is the same with SEF Advance.
As always, the performance delivered is dependent on the server hardware and server tuning.

Joomla 1.0.x
There will be an open source SEF component for Joomla 1.0.x.

We have XE2/OpenSEF running and testing on 2-3 different sites.
With the availability of the J!-RC now, we will be upgrading those sites to J! 1.0.x-RC.
Popular components are being tested on these web sites.
Some components already have advanced SEF files available (sef_ext.php).
Those sef_ext.php files we have, we are testing.
Feel free to contribute yours for testing.
More advanced SEF files (sef_ext.php) are being developed and tested for some very popular components.
These will be released along with the component when finished and fully tested.

We also have a test site running advanced SEF using only the core, no component.
Right now it only requires changing two core files.
Currently running on M 4.5.2.3, will be changed to J 1.0.x-RC now that it is available.

Timelines - completely unknown at this point. Please don't ask.
Just wanted let people know stuff is happening.
Arto is working on XE2/OpenSEF beta 3.
Marko is working on all these other toys (fun for me, keep getting new things to play with).

There will be one or more open source advanced SEF or URL re-writing solutions for Joomla 1.0.x.

Just to throw my 2 cents in the debate :)  I would *love* to see not so much SEF URLs as Human Friendly URLs, for usability factors as Ken mentionned.

I used Xaneon for a while, and had to discard it :(  It was brilliant, but...  In terms of ressources, it was not viable.  I'll have to look at what you guys have done with it.  I used it on a site that got a lot of traffic (2,000+ visits a day, with a forum), and it just increased loads on the servers something fierce.

To me, both pathway and urls are going hand in hand.  Neither do what I would like them to do, and an ideal solution would be something that works like XE2, doesn't shove server loads beyond acceptable on big sites, *and* also delivers a "mirror" of the url in the pathway.  For example, http://mysite.com/news/latest/today would have a pathway of home > news > latest > today

I do think this should be a function of the core.  I agree with Rey's point of having to prioritise, sadly, it's a fact of life. 

Anyway, looking forward to see more on this

Usability goal:  Pathway = URL = Menu structure
With you 100% on that one Nic.


XE2 performance
Arto has stated he was "first focusing on making it work and then making it fast." (paraphrase)
I have seen some of the discussions on reducing the number of queries, caching, etc.
Don't know if any of these will make it into Beta 3.

Once we have stable releases it will be interesting to do some benchmarking.
I have seen HUGE perfomance differences on ad servers running phpAdsNew and Max Media Manager
by properly tuning MySQL and Apache, using PHP caching software, and other techniques.
Have not "tuned" any Mambo/Jooomla servers yet.
Will be fun to see the results.

I absolutely agree with the human, rather than SEO, reasons for this.

I also understand and completely support the technical decisions behind the current state of affairs.

There is no great conspiracy on Emir's part - just the opposite, in fact - and to pursue that line of thinking is a massive red herring (I do hope that Joomla! fish logo design isn't a herring - I'm no fisherman - at least it's not red  ).

Personally, I am quite happy to buy SEFAdvance because I want to achieve an aim (useful URLs) and that is currently the best way for me to do it.

That aim is user-oriented and front-end-driven. I don't care if oompa loompas have to travel down the wire to every visitor's computer and manually re-arrange the URL, so long as they do it reliably, quickly and cost-effectively. I want my URLs. I also don't mind paying because the price is very reasonable. I want my URLs. My perspective might be different if the price were higher (then I might be tempted to get all moralistic about Open Source principles, purely in pursuit of my aim, you understand). Remember, this is all driven by a precise, focused, mercenary aim, perceived from the front end. I want my URLs.

And that is the point. It is a simple matter of perspective and priorities.

The dev team can see all the stuff behind the scenes which most of us don't delve into in great detail. They can see the technical obstacles and have an onerous responsibility for the stability and performance of the core application. They can see the goal of a better way of doing things in the future. I'm glad they do. They do a superb (unpaid) job on all fronts.

But there's a forest in them there trees: and I want my URLs.

And so do most other users and their visitors. Very much. Very much indeed. And those visitors don't even care that we are running Joomla (or Mambo, or anything else), much less how it actually works, because they are looking for content. But they do notice the URLs.

So my two zlote, for what they are worth, is simply that anything can be achieved if it is moved to the top of the priority list and enough 'resources' are thrown at the problem.

It might be time to at least reassess the relative priority of this issue, the importance of which to front-end users may have been under-appreciated.

Tables are important. I find the profusion of (now) unnecessary tables in Joomlambo quite annoying on occasion. But visitors don't see tables. And, from what I understand, the best screen readers are pretty good at interpreting them. Everybody sees nice URLs and finds them helpful.

In the meantime, I will do whatever it takes to get my URLs.

To redefine what has previously been missinterpreted, I am not saying restructuring the database must happen in version 2.0 (or previously 5.0).
It may as well come earlier, maybe in 1.2, 1.5, 1.7, I don't know. Currently we have somewhat clear roadmap only for 1.1. But NBS structure of database is planned and at some point we will focus on that. You must understand that this is a big job. The current database structure is still based on early 3.0.7 version of Mambo and it's very much outdated for functionality that we have today.
Therefore we must find a new, optimal structure that will allow for infinite category levels, get rid of Itemid and open path for better SEF URLs. This will involve massive core changes and probably break compability with many 3rd party addons.

Forcing SEF URLs on the current structure leads to an interim patch solution, hard to maintain with open issues that just can't be solved (and that's exactly what SEF advance is).
That's why built-in SEF does the best job as it is today. It requires no maintenance, following the structure logic and have you heard anyone complaining about bugs in it?

So if you need better looking URLs you always have a choice of installing one of the 3rd party addons. No matter which component you choose it will increase the load, create bugs and open many issues. Some people can live with that, others not.

You are right, anything can be achieved if its given sufficiently high priority and enough resources are thrown at it - but this is not a case of throwing resources so much as working on what is achievable within the scope of the available resources and within the roadmap.

Tables are important - but only if they contain tabular data.  Otherwise, they are not just unimportant, but preventing W3C XHTML and WAI compliance.

The best screen readers can give reasonable performance in  interpreting properly used tables, ie. those containing tabular data.  Tables used in other ways, as they are now, not only make the sites less usable, but for some, inaccessible.  Making Joomla! compliant is, for me, a priority.  There are few countries in the world that don't have laws relating to accessibility.  This is not just a matter of being able to sell Joomla! into government, or NGO's, which we can't do until it meets WCAG compliance, it is also an issue of risk.
The Sydney Olympics website is, as far as I know, the only one ever taken to court and ordered to be made more accessible.  In NZ, complaints are addressed outside of courts, but designers are nevertheless at risk of being ordered to make changes any time they put up an inaccessible site.

Tableless design is only one part of meeting compliance.  It is, however, a part which can be met soon without compromising the rest of the development which is going on.

Most people want better URLs for the content and sure a extra component will increase load, create bugs and open may issues, but why not give the people the choice from the Core, i have looked the last weeks in OpenSEF( Xaneon ), sef404 and an old sef component from Greg MacLellan, all these components are overloaded if you only need nice URLs for the content, so i put all this into the Core buildin SEF ( includes/sef.php ) and add the settings into the Global Configuration. Here you have now the choice to use compact mode ( is the current way of sef.php and have the choice to install an 3rd party addon) or an advanced mode.



There is also added support for sef_ext.php which i guess comes original from your SEF advanced ( Xaneon supports also this but in a different location ) if i`m honest i prefer the component/com_component/sef_ext.php way makes it for my "hack" independent, means you can use this files but don`t need the SEF component ( which ever ).

And at least it needs less resources than one of the 3rd party components and it is free..

You can see it currently working on http://www.joomladeveloping.org

Hi,

@ Marko, this is looking very very interesting ! Wish Joomla had such a SEF/SEO page integrated 

My Joomla has it 

I've built a SEF component running based on Greg Mac's work, to help manage the URLs.

Still very alpha, but it works..

For a simple reason that the core team would be overloaded by support queries and bug reports from hundreds of thousands of unhappy users. We would end up spending the resources on something that can't be solved or supported properly because of the current core structure.

And I think core team resources are better spent on something all can benefit from. This way the support load ends up on 3rd party developer, not on the core team.

Instead the way forward is restructure the whole scheme and implement new SEF in core properly based on the new structure.

Anyway this is just my opinion, also the reason why I haven't integrated SEF advance in core 2 years ago.
But if the rest of the team thinks it's productive to integrate whatever 3rd party SEF that currently exists in core right now, I am fine with that.

I (we, even?) do understand that. And that it will have wide-ranging consequences.

I think it would be a mistake to allow a groundswell of popular demand to force into the core an imperfect patch which it would be unwise to integrate. Just because something is popular, does not mean it is the right thing to do.


It does an excellent job of what it was intended to do - help search engines. What people are asking for really is human-friendly URLs.

As you say, at present the best way to achieve that is using a 3rd party add-on. Be it yours or anyone else's. I have no problem with that. Nor with the fact that you charge for your version. Purchasers expect, and get, support for a product which needs a level of continuous development to ensure that it works as well as possible in as wide a range of circumstances as possible. Seems like a perfectly reasonable deal to me. I hope we can move beyond personal slights based on that in this discussion.

My point is simply, don't underestimate how important this is to people, and take account of that fact if at all possible within the constraints of what you and the core team know to be technically possible/sensible, both now and in the roadmap.

I've complained about built-in SEF, since upgrading from 4.5.0.

- as get the item IDs slapped on end, so can have multiple URLs for one item (mamboserver had whole thread based on this, tho took time to get going).
This is surely SEU - search engine unfriendly. Google dislikes duplicate URLs (should rank one page, and penalise others with different URLs); then, which URL should others link to?; get dilution of Pagerank (or however you might call this, for all search engines - the potential benefits of inbound links).
Key reason I abandoned SEF404 (for one page, saw five or more URLs spawned in about ten minutes), and chose Xaneon.

(Maybe itemid problem is a little different - but surely means the "friendly" in built-in SEF is misleading.)

Also, with the item ids especially, URLs surely aren't Cool - set to remain for long time.
Over time, this too is unfriendly (to search engines, also to humans - who might find themselves clicking on links that no longer work. Plus to site managers, who may find themselves putting in loads of redirects if, say, get whole new set of URLs after Joolma! upgrade [latter has happened w Mambo; hopefully now w J!])

I'm not sure I fully understand the implications of the modifications you have made, Marko.

I notice on your test site that with multi-page articles you get URLs like this:

http://www.joomladeveloping.org/menu/Jo ... es.html/1/

But presumably you could leave the suffix box blank to avoid that problem?

Will you post your hack?

Will it work on 4.5.1 ?

I`m working on this was happy enough that the multipages work LOL but right looks in this way not so good will change this maybe to look like this:

http://www.joomladeveloping.org/menu/Jo ... nes.html#1

or like this

http://www.joomladeveloping.org/menu/Jo ... nes_1.html

If all is working the way it should ( currently this url above is the last issue ) sure i will release this hack.

I haven`t tested this on 4.5.1 only on 4.5.2.3 and Joomla 1.0

Further to complaints re built-in SEF, here's extract of a post on webmasterworld:



Mentions Xaneon can fix this, so too SEF Advance.

But, should people have to pay or use a free third party component to fix a problem that Mambo (and now Joomla, till revised) creates?

First - Jommla is an absolutely wonderful CMS.
I am here because it is an incredible piece of work. WOW. WOW. WOW!!!!
Reality - Joomla creates multiple links/URLs for one content item.
Reality - this will not be fixed until there is a complete restructuring of Joomla.
Reality - many people need to deal with this NOW.

Work-arounds are needed now.
Some of this may be done in an advanced SEF component.
Some core members are the people most able to describe the issues, and the work-arounds.
Some core members have already solved these problems in their commercial components.
For this reason, it is not discussed.
Prove me wrong.
I am a moron, please show the world with the documented fixes/work-arounds for all of the ItemID issues.

Obviously I am of limited mental resources, please explain to me and the rest of the planet what the issues are and how to work-around them with the tools available to the average Joomla user.
Thank you.

Regards from another clueless Joomla user and rabble-rouser,

KenDohg
(my old sailboat racing nic)
(while the rest of the people were safely sitting down, the bowman and I were gibing the spinnaker)

Hi !

I do understand and agree that all this comes down to how development priorities are set, in accordance to available resources, ability to manage them efficiently,... as previously exposed. I, however, disagree on putting SEF way down the list as it seems to be now. If this waits for a major DB rework, then we are probably one year before seeing anything practically usable by end-users.

I think (and this is just my voice), that SEF has a higher priority in the whish list than tableless output, or cleaner code for example, because this is just an issue that matters more to the current user-base of Mamb*/Joomla. I believe (maybe wrong though) that a large majority of M/J users are individuals, non-profits, or small to medium size companies. Even when used in larger organizations, I believe M/J is used for sites that are in the small to medium range in terms of hits per day. At least, a large majority of M/J sites are.
For this type of users, I don't think legal issues relating to accessibility will be a decisive factor in using M/J. Performance issues may not be such a problem either (at least until they rank so well in S.E. that they get several thousands hits per day!)

But for all, it will be very important that their site be found easily and rank well in major search engines.
This is why I'd vote for improved SEF built-in the core ASAP.

@Predator : looked at http://www.joomladeveloping.org. Looks very good. Did you by chance tried that with Mamblefish ? if not, any news on releasing your hack ? I'd very much like to test that either on M. or on J. to see if I can do better on my two biggest issues : SEF and Multi-languages working together ?

Regards to all

So, is this going to be fixed in the interim or not, then?

Is it going up the priority list or staying where it is?

Can we have a pronouncement from the core team, please, so we all know where we stand?

Or a poll to establish how important it really is to people?

The issues are clear, I think.

Of course, any survey would have to be meaningful. I didn't even understand the ill-thought-out gobbledegook which passed for one at mamboserver, but then there are lots of things I no longer understand over there, which is why I'm here.



What did you used to race, Ken?

Having purchased several licenses of SEF adv I must weigh in here a bit. I think the money I spent was well worht it. Solved a problem for me at the time and continues to hold that dog at bay. So I am a fan of Mr. Sakic.

That said I can also see KenMCD's point in that he finds it suspicious that the member of the dev team that is responsible for sef also sells a component addressing a more advanced version of sef. On the surface it does call into question the motivation of the developer. I am not sure that any solution proposed here will abate kenmcd's point.  And therein lies the dilemma. When working on a project such as this one, when does the developer's contribution to the project as a whole conflict with his/her ability to earn a bit of income from the fruits of his/her labor?

We all know another developer that was a contributor that also sells commercial components and was also a contributor to the Core. I guess it really is a matter of integrity. I would like to think that everyone contributes to the success of this and many other open source projects in many ways. It isn't just the developers, but it is the entire community right down to the people that read the information in the sites that are built on this code base. Without the interaction and activity, a lot of the development just wouldn't progress.

I don't know how any developer or team member for that matter doesn't benefit in some way from the interaction of the group as a whole. I believe in the integrity of Mr Sakic. I also believe in the fact that although he may be better at URL rewriting and Mambo/Joomla core than most, there are plenty of people on the team that would recognize it were he to hold back the development due to his desire to gain financially.

Just my two cents. To think that all of this has been built by people that wanted to do this work rather than people who are paid to do this work is an example of the ability of a people in a group to find the things they like to do best and stick with it.

Ken you make two good but dialmetrically opposed comments:

> Reality - this will not be fixed until there is a complete restructuring of Joomla.
> Reality - many people need to deal with this NOW.

Complete restructuring of Joomla cannot happen soon enough to be available 'now'.  The point is, a scalable SEF solution is only possible with a restructing of core information.  While there are a few free and commercial offerings, *all* are being let down by the way the core has been structured and it's only of the remaining legacies of the orginial Mambo 4.0 we have to content with.

I must emphasise that it is a priority, but that 'top' priority spot is also shared with many other competing interests.  We are revising in detail the roadmap for 1.1 and a few of the dev team will be able to meet in London in a few weeks.  So no doubt there will be a few heavy php and db schema discussions going well into the night around the bar and diagrams drawn on napkins...and yes, SEF is on the agenda to be looked at but it is one among many BIG issues that need to be attended to.

I can also assure you that nobody on my team 'rigs' the core code for their commercial advantage.  There has never been a time were I have asked for a feature to be included and one of my team has said 'no' because that would affect the sale of their commercial solution.  It's often times the exact reverse where small tweaks done on commercial jobs are fed back into the core so that everyone benefits. 

I certainly do not hold the opinion that Emir in an way holds back the core by not including his commercial solutions.  I've never asked him to and I don't really see the need.  In my view it's the other way around, the core is holding him back from doing some really creative things.  When we do start improving the core though, Emir will be right up there with us designing a better system from which "everyone" can benefit.

thats good enough for me to belive in Emir.

Reality - Fixing it (or improving it) permanently and working with the current code limitations NOW are not diametrically opposed.
If that were true, that would mean they are mutually exclusive - I do not find that to be true.
Yes, the underlying structure could make advanced SEF much easier and more efficient.
Does that mean better solutions or more open solutions do not exist? - No.

Frankly I am disappointed you are here defending this situation.
Everything else I have seen points to your high integrity and incredible selflessness.
In the accounting profession, I was held to the highest standard - "independent in appearance as well as in fact."
Third-party endorsements of my integrity did not count.
"Beyond reproach" was the goal.

I am just another moron joomla user looking thru the smoke and mirrors.
As I dig more, as I learn more, I am more and more alarmed.
My latest find . . . from here:
http://help.mamboserver.com/index.php?o ... 3&Itemid=1
Title Alias: This field is not used by core.  SEF scripts and dynamic title/meta scripts use it and it may have a future use.
Almost nothing in the forums or any where else about this field.
What caused me to start investigating this field? - it is used in advanced SEF components.
Isn't that just amazing? - a field included in the core, but "not used by the core."
Appears to me it was probably added to the core to support a particular SEF advanced component.
Lots of posts asking what it is in the old forum. Surprise, surprise, no answers.
Along with the SEF "hooks" in the core . . .
Barf.

To the Joomla User Community - there will be an advanced SEF component available for Joomla 1.0/Mambo 4.5.2.x in both a component with additional features and in a core hack regardless if there is any help from certain core members.

Want to make me a believer? - have Emir start showing up at discussions regarding workarounds for limitations in the Itemid system in the current Joomla. All the Itemid issues must have been addressed and solved in SEF Advance. How else could it work reliably?
Emir (and other core members) the discussion on this problem is currently centered here:
http://forum.joomla.org/index.php/topic,4259.0.html
Please log-in and contribute to the discussion and the solutions.
Any SEF component will have to deal with all the Itemid problems - please share the KNOWN solutions.


Is everyone on the planet just unbelievably stupid, including me, or is this a problem which needs to be addressed?

Ken here's the summarised long answer then.

SEF, Itemid, menu and pathway issues all get solved with what we have coined Node Based Schema (NBS).  It a way of representing heirarchial data of meta objects and then you attach the object specific data in some way.  It means that you can know where an object fits in without knowing exactly about the object.  Converting to this will take some time and we need to determine the best time to integrate this into the core, balancing all the usual things like backward compt. etc.  I honestly don't know if there is a middle ground but we are looking into it, but it's not going to be solved overnight.  Would I be happy to have SEF Advance put in the core tonight for free?  Probably not, because it does not solve the root cause of why the problem with Itemid exsits.

In Joomla! 1.1 SEF support will be moving to a Mambot so you can roll your own free or commercial version and charge as little or as much as you like for it.

Re the Title Alias field.  It's a common technique used in many a blogging application.  Anyone is welcome to use it and then next schema change will probably mean that all tables will have it.  I have actually seen other SEF components that duplicate it's effect instead of using it directly.  There are also a number of 'sleeping' fields in the schema.  I can think of a least two others.  There are a number of fields that were put in around 4.5.0 time that didn't get properly used until a later versions.

Re integrity...just because you disagree vehemently with my stance doesn't mean I lack integrity.  It just means you disagree, albeit very passionately.  It would follow from your reasoning that any commercial component, module, template or mambot that I or any other member of the team produced would be subject to that same call to make it free in the core...  On that basis I could never do anything to profit from my involvement in Joomla!  Isn't it the exact opposite?  The more commercial support Joomla! get's the more seriously business and government will take it as a viable enterprise solution because they have someone to call if it breaks.

Ken, the changes we are looking at making will likely make Emir's advance component obselete overnight.  Do I hear him objecting?  Of course not.  Will he be integral in its design?  Most certainly.  So what is the real issue here.

Re Emir...he is not around at the moment for a personal reasons.  Those close to him know why.

The final result is that it's on the table and we are going to work on it.  But right now I would really prefer to give priority to making Joomla! sites literally readable to blind people than to placate those who can't fork out a few bucks for pretty url's.

Hi Andrew and Ken,

Despite the personal issues I happened to be around and read this.

Just a small addition to what Andrew already said. Title alias field was added for benefit of a large Mambo customer: Devshed.com. We wanted them to use Mambo and they had this requirement so we put it in core. After that several 3rd party components made use of this field. So Ken sometimes it's better to ask than speculate.

Regarding the question how the things are solved in SEF advance I already explained that. Just go up and read. It's a patch on patch solution (patched for years) that doesn't solve the base problem: core's structure.
The patch solution requires support and constant maintenance. In the same time increasing the load. That's why it's not very suitable for core.

So many words to expose the real issue wich I see as being the timeframe for fixing itemid. Was this a roundabout way of trying to force that issue to the top of the list?

@masterchief
I am not impugning your integrity - please do not take this as such.
What I am questioning is a situation.
A situation which has likely been created over time.

There is no disputing that there are elements in the core which support advanced SEF components.
How and why they got there is actually irrelevant (but interesting none the less).

Everyone must acknowledge that there are conflicting priorities in all projects - open source and commercial.
Limited resources are allocated with great pain in all cases.

Let's get back to the original question - "When will SEO be integrated?"
I obviously have an opinion why this has not happened in the last 18 months to 2 years.
Whether I am wrong or right, the priority has not been to put advanced SEF into the core.
Or it would have already happened.

The Core Team cannot do everything on the wishlist when desired. This well known.
Contributions are very valuable. But, as acknowledged by the current discussions to create better communications with the Core Team, Core members knowledge and input is crucial to the completion of certain tasks.
There are people working on this SEF issue now who could use the knowledge of the Core Team to complete the task.
My opinion again - certain people could be more helpful to the effort.
The silence is deafening. 
So much of the info needed is just simply missing.

. . . just did a Preview and saw the other posts . . .

So Title Alias was added to the core for an SEF Advance customer.
It was added for a commercial customer.
Did I miss something here?
This is somehow a mitigating circumstance?
Geez. I must be completely freakin' mad.