The Joomla! Forum™

At what level of release does the master plan say SEO will be integrated into the CORE?

I just had a heart attack when I realized the two sites I'd converted to Mamb* over the last 6 months had both fallen off page one for their Google searches...

SEO at least page names and SEF are in the 4.5.2 is it turned on in your config?

Good question Tjay:  when I first started migrating over, I read some posts pointing out problems with turning on the SEO--so I shied away from turning them on.  I thought that was the reason the 3PD solution came about...

If I can be educated; is there any problem with the built-in SEO, or the dynamic page titles?

Not that I can see, I use it on all my sites even one done with phpshop.
The only problem I ever had was with SMF forum, but even that might be fixed now as I have not stayed current with it.
My most challenging site was using a secure server https / SEO names / SEF all on one site
works great. Just have to turn it on and change htaccess.txt file to .htaccess
There are some server settings that could mess it up, mod rewrite I think

malibu wrote: Good question Tjay:  when I first started migrating over, I read some posts pointing out problems with turning on the SEO--so I shied away from turning them on.  I thought that was the reason the 3PD solution came about...

If I can be educated; is there any problem with the built-in SEO, or the dynamic page titles?

In all my sites SEF is ENABLED, and they are 100%. You should enable that without problems.

:: edit::

Ne'er mind.  I figure it out by trial and error...  Links look kinda hokey with SEO on, but I trust y'all that they're gonna crawl better.

hello @malibu,

i believe it SHOULD crawl better.. IF I AM A SEARCH ENGINE i would prefer reading:

yoursite.com/component/option,com_frontpage/Itemid,1/

compared to:

yoursite.com/index.php?option=com_frontpage&Itemid=1

IF I AM A SEARCH ENGINE, i'll surely hate rading that "?" after the .php and the ampersands in betweens..

IF I AM A SEARCH ENGINE, i'll surely love reading:

yoursite.com/yousites_home_page.html

^^that is how the advance SEF component works (sakic)

UNFORTUANTELY, im ONLY human,.. IM NOT A SEARCH ENGINE.. so i cannot 100 percent guarantee what a search engine REALLY loves to read/crawl. but based on users feedback ... the Advance SEF really works and gets better results.

guilliam

btw.. anyone really thought IM A SEARCH ENGINE? wow cool that! serch engine bot that can even write and post in OSM.. ahihihihi!

ditto

Okay... now that I'm slightly MORE read up on this, I guess I need to append my question:

At what point in the developmental level will ***** CMS have a much more 'robust', stronger, more aesthetically pleasing SEO/SEF system.  To my untrained (in the world of SEO) noodle, I would think this would be critical to any CMS.  Dynamic sites must crawl incredibly well for ranking on Search Engines... if a site won't rank well, it'll never get traffic.  I can think of one ecommerce site owner who went back to static pages for his site and put himself at the Google Top 3 for several major web searches for his store.

Or am I unknowingly jumping into a political issue with 3PD's and I should just be quiet now?

"...and I should just be quiet now?" -dan

hmmmnn.. i dont see shuting up resolves any issues. at any rate, pls check the URL given below.. that maybe the solution you were looking for to address the concern of this thread.

http://www.sakic.net/scripting/mambo/sef_advance/

its the url i wasnt able to post in my prior reply. check the skype.com site that used the component..

i see the point in the integration of this matter in the core too! and obviously it will greatly help the CMS in so many facets... otherwise,.. this step will be putting other TPD's out of business in the SEF/SEO side of the story. BUT indeed it will be for the greatest concern IF leaning on the ~community~ perspective.

guilliam

@tjay,.. sir i do strongly support the concern (wishlist) raised in this thread. looking forward for your reply.

guilliam

ow, maybe a usefull tool:

i've created this a while back for testing purposes:
http://dsl.tim-online.nl:8080/predictor/

it's a script that simulates how google will see your pages. It might not be fast all the times, it's running on a DSL connection, but it's usefull.

nice tim!

guilliam wrote: nice tim!

the name is Adam actually

You can also check out http://www.xaneon.com. Not sure when something more robust will make it into the core.

Nothing new will make it into the core until a core developer is no longer profiting from a working product - a commercial product.

You may notice in the 4.5.3 CVS changelog the same developer has made some changes to the SEF already included. Apparently since this is his expertise, he is the one assigned to this component.

This is an obvious conflict of interest.
And the obvious reason why a more powerful SEF component is not included in the core.

kenmcd wrote: Nothing new will make it into the core until a core developer is no longer profiting from a working product - a commercial product.
...
This is an obvious conflict of interest.
And the obvious reason why a more powerful SEF component is not included in the core.

Yeah... that's kinda what I gathered from my research.  Guess I did step in it! 

I guess I'm conflicted about what to think about it.  I'm all for someone being able to make a buck from a good, quality, product.  But when there is a basic functionality (solid SEF URL's) missing from a fantastic product like this... I guess I don't understand.  I'd pay for a Paypal IPN module, or something that meets a business need that's specific; but if this is something that is holding OSM back from fixing a obvious shortcoming of the CMS--I would have to agree with your assessment, Ken.  If the individual in question isn't willing to develop the core in this area, that's his choice.  But I would task the Dev. Team with the responsibility of finding someone else to do it.

I'm sorry, not trying to bring controversy.  But I think given the sting of current history, and the betrayal of hidden intentions... now is a time when we can help ourselves by being open and honest.

The same person coding the SEF in the core is selling the Advanced SEF.
How can this not be a conflict of interest?

With all the very strong and very vocal opposition to the commercialization of Mambo it seems rather odd to not point out the obvious.
This conflict of interest was pointed out previously in the Mambo forum - no response.
It needs to be discussed.
As you said, open and honest civilized discussion.

There are many, many, many posts in the Mambo forum (and now continuing here) requesting improvements to the SEF component. The demand for this is huge.

This is why someone is selling a lot of components, and probably making a very good profit on their work.
This person is also on the Core Developer team.
This is why the core SEF component has not been improved in spite of the huge demand.

Nothing wrong with writing and selling commercial components.
But you should not also be on the Core Development team.
One or the other.

The conflict of interest issue is a major criticism of the Miro / Mambo Foundation relationship.
No one wants Miro controlling the core and using that control to make a profit.

The Core Developer team controls the code and what gets added, or not added.

How is that any different?

Nice points there Ken...

And to think I would least expect that to come from you.

Here's more... before the announcement of the $ambo Foundation, MamboDev which is owned by a member of the Core Dev Team, phoenixed into JamboWorks which is now being run by at least five of the Core Dev Team members themselves (See "About Us" page of OSM).  I don't see any conflict of interest here, but hey, is there anything that the community should know that we are not aware of regarding the real score in the Dev Teams' "walkout" from Miro's control?

To clarify, I see absolutely nothing wrong with anyone associated with Mambo/OSM, including the core team, running a consulting business.
It makes perfect sense.
And there is no conflict of interest by doing this.

The conflict I see is when something is obviously not being adding to the core because someone is selling it.
That is a conflict of interest.
And not good for the users as a whole.

If every core developer started selling the high-demand components, where would we be?

Gosh this is a tricky one

I support anyone's right to make money out of added-value services for Mambo. I use SEF Advance and I'd like to see better SEF in the core product.

How to resolve this?  The only obvious way is rather dramatic

This has already been raised and discussed many times on the old forum.
As this is the new forum I will copy the respond again here.

It's not true that better SEF is not being adding to the core because someone is selling it. The reason why SEF advance type of SEF isn't part of core is really technical.
Firstly it makes too many query calls to database which increases the load pretty much.
Standard, built-in SEF that I also made doesn't make a single additional database call which makes it very quick.
Besides it is following the content structure and that's why it almost doesn't require any maintenance at all. Having more advanced SEF in core on the current database structure and having thousands of users would create all kind of problems and issues which will just lead to patching without ground solution.
SEF advance is not clean and solid bugfree solution and requires me to activly support my clients every day. This is something that I would not be able to do if I had thousands of users.

Of course we are planning to change the database structure soon which will allow for better integration of more powerful SEF (going to NBS and infinite level of categories).
Don't think that I, as core developer, am holding back core in order to make cash (like some evil souls here have suggested). Anyone in the team is free to code whatever the community want.
There is no conflict of interest there. I made SEF in Mambo in the first place and I would have included SEF advance at that time if I felt that it is a solid solution for core.
If you or anyone else can make a solid, fully functional, bug free SEF code with low maintenance grade on the current DB we would be happy to include it in core today.
But believe me at this point it is impossible to make a clean SEF code before restructuring the database.

I would also like to poit out that there are plenty of other, free SEF components you can use in the meantime. Some will work better, some worse and neither will work perfectly until DB is restructured.

Yes!  That's what I'm talking about!  Open, honest communication!! 

The only thing you missed Saka, is TIMING!?  When will the database be updated to the point where a proper SEF solution can be implemented with the core?

I HAD read some of the old threads which pointed to some misunderstandings, and questioning of motives.  And you seem to be conscious of the potential for people to perceive a "conflict of interest" for Core Developers.  I cannot speak for others, but while your answer satisfies me... I think this is a matter that the Core Dev team needs to consider taking a 'position' on for the community as a whole.

I understand much better now.  In order to implement a solution which will not negatively impact the performance of the core CMS, a database restructure is required.  BTW... open source dbase restructures can be PAINFUL... ouch.  So, just let me know when this NECESSARY advancement is slated to take place, and I'll get my shots from the nurse.

Anyone can try their hands on sef404 or 404_SEF by marlboroman. Current release is PR1 and it's at sourceforge.

Sourceforge:    http://sourceforge.net/projects/sef404/

Note: As Saka explained, SEF can make too many queries to the database server which increases the load. The last time I played with sef404, my host was forced to temporarily suspend my account. Play and use at your own risk. It's GPL'ed, so anyone can pretty much improve it. But then again, the problem is with the current structure/architecture. Anyways, go get your hands on it.

Malibu: I understand that some people without enough knowledge about Mambo and it's history may perceive a "conflict of interest". That's why I explained this many, many times on the old forums but people are obviously too lazy to do a search.

In the team we have accepted the policy that our only objective must be to do things that are for the good for the project as a whole and that prevents conflict with anyones personal aims.

Regarding the database restructure it was planned for version 5.0. Right now nobody can't give you the exact date, especially not after recent happenings.

Dr. Evil here.
Thanks for the reply.
Never got a response to the same issues raised in the Mambo forum.

When I was a CPA doing financial audits, we had to be "independent in appearence as well as in fact."
That is right in the ethics code.
This is so the auditor's independence is held to the highest standards.
The public could then have faith that the auditors are truly independent, and that the opinion rendered on the fairness of the financial statements is truly unbiased.
"Independent in appearence as well as in fact."
I like that.

Back to the problem at hand - getting an open source advanced SEF component.

Xaneon Extensions is being released to back to a "GNU General Public License (GPL), allowing the XE2 codebase to be more easily integrated into any other Mambo-related projects."

Looking for Developers to Take Over XE2
http://xaneon.com/news/20050822-xe2-dev ... nding.html

At this time, this seems to be the best opportunity for open source advanced SEF.
With the XE code available as open source perhaps others will be more inclined to provide some of the fixes as well as the community can pick it up and start providing some of the support.

They say they will be releasing a Beta 3 soon which fixes a lot of the known problems.
This code base should be a great start for a new developer team.

Lots of people are using XE on web sites without any problems.
Some of the problems are caused by 3rd-party (3P) components (same with Advanced SEF).
An open discussion of this in a forum would lead to a better component.
Right now much of it is not discussed because I imagine it is a "trade secret."
I have been collecting information from the Mambo forum and other sources discussing how Advanced SEF works and how to make modifications to make it work with various 3P components.

Quite awhile ago I also saved all the XE documentation (because the site seems to come and go).
I will commit to creating good PDF, HTML, and CHM documentation as my contribution.
And to promoting the project.
New name - OpenSEF  (based on Xaneon Extensions)

Anyone else in?

Saka wrote:but people are obviously too lazy to do a search.

That's me - too lazy to search.

Ken,

I do agree re the urgent need for an Advanced SEF which is almost expected these days, however Saka does have a point re DB restructure.

The main problem I have had with mambo since day 1 was the whole concept with its content structure (the whole categories/sections/items concept).

I think in v5 it was planned to be restructured into a more logical folder/item (or folder/folder/item, etc) structure and I think as part of that restructure (or very soon after) the advanced SEF functionality should be added.

At such time it should be easier to implement it without having to reinvent the wheel twice (ie once now and 2nd time after DB restructure).

Anyway, thats my 2c.


Cheers,
Max

typera wrote: I do agree re the urgent need for an Advanced SEF which is almost expected these days, however Saka does have a point re DB restructure.

The main problem I have had with mambo since day 1 was the whole concept with its content structure (the whole categories/sections/items concept).

I think in v5 it was planned to be restructured into a more logical folder/item (or folder/folder/item, etc) structure and I think as part of that restructure (or very soon after) the advanced SEF functionality should be added.

At such time it should be easier to implement it without having to reinvent the wheel twice (ie once now and 2nd time after DB restructure).

I just popped over to the Xaneon site for a quick read (Like others here, SEF output is now high on my priority list - having just launched an online shop using *ambo/mambo-php-shop)

Really, there are only two options:-

• Take over the "Xaneon Extensions for Mambo" (or implement something similar), or
• Change the database structure of *ambo

The decision then comes down to

• Which of the two is better ?, or
• Do we do both ?

I'm not a programmer, but I'm happy to become a "Beta" tester for any new development

I just implemented 404SEF for a short-term solution, and it seemed to go in clean.  No broken links at least.  Don't know how bad the dbase hit will be, I'll have to watch.

I'll help with docs and provide testing platforms with my reseller acct if need be, but alas, I'm not a coder.  EX seemed to be 'dead' on their site, but if it becomes viable, I'll kick in my support until the glorious day of v5, when angels will sing, and dbases will be restructured, and we'll all crawl the Search Engines with ease!!!!

Great thread, everybody. This is a core issue, IMO.

This is the very reason I hadn't migrated my sites over to *MabbyWabby earlier; I had terrific search engine positioning, and wasn't going to give it up. I've always been able to gain top five in the search engines, and it would kill me to lose that placement!

Well, I'm still not happy about the way the site will be crawled. But, certain anchor pages, with a couple of thousand links in to them, will now remain as "/index.html" pages only; with links leading back into the Mabby site. I can't wait to use the new software, and I believe this will do the trick. (It's a free coloring book, that's why everybody links to it.) Thanks Brian @howtomambo.com for his advice on this. He gave me the information I needed to confirm my ideas and settle my concerns inside about 30 seconds.

Now, all I need to do is move all those bajillion pages...

(*Maybe my pretty tabby cat named "MabbyWabby" will help me?)