Simple SEO URL (OLD version) [support thread]

[nagelkruid]

Again, this is part of zen default links, it's not like ssu automatically append that in.

No, no, i understand that, you are right, i should probably put it in the exclude list although it will never be used anyway heh.

Ok cool, i still have some of the favicon's left i think those shouldn't be default behaviour. (but i am not sure/really don't know :)
Here's the links i see:

/winkel/kraamkadootjes-c-76/sort/20a/page/favicon.ico

/winkel/voor-op-de-vloer-c-18/sort/20a/page/1

/winkel/alles-voor-piraten-leuke-piratencadeautjes-c-107_112/favicon.ico

so in the top 2 it seems very similar sorts to me but one of them gets the favicon added??
The latter is just plain category listing, almost none of the catlisting adds the favicon.ico.
Should i expect those?

One more observation;
i see this link:
/winkel/meubeltjes-c-35/gclid/COTyn7PhmJcCFQ4i3god6j6pDA

maybe more for documentation, but is it possible the glid is actually a typo and Set Query Key's Exclude List should actually be default set to zenid,gclid ^_^

[yellow1912]

You are right about the gclid, thanks for the correction btw.

The favicon.co appended to the links is mysterious, but not a big problem. Remember that bots crawl the site just like you do, they follow links. And since these links (those with favicon appended) are NEVER generated anyway, so such "wrong" links only appear in your who's online listing. This can be considered an annoyance rather than a bug, and it has no effect whatsoever.

[nagelkruid]

The favicon.co appended to the links is mysterious, but not a big problem. Remember that bots crawl the site just like you do, they follow links. And since these links (those with favicon appended) are NEVER generated anyway, so such "wrong" links only appear in your who's online listing. This can be considered an annoyance rather than a bug, and it has no effect whatsoever.

Yes, i feel exactly the same about it, although the favicon is never with spider sessions and always with client sessions, but it seems odd.
If i follow the link i get the page i expect with the favicon.ico in the url address, but i really wonder if the live session is actually seeing that same thing in his browser url bar.
I also noticed some double sessions that i think may be related to this behaviour, but at this time i am not sure, i'll update if i have more relevant info.

on the suggestions bit i have one more consideration for your documentation. on the rubik link http://wiki.rubikintegration.com/zen...www_and_nonwww it says
RewriteCond %{HTTP_HOST} ^example\.

I believe in that example it should read
RewriteCond %{HTTP_HOST} ^example\.com

or it gets rewritten incorrectly?

cheers yellow,
really appreciate your input, thanks a lot.

[yellow1912]

Yes, i feel exactly the same about it, although the favicon is never with spider sessions and always with client sessions, but it seems odd.
If i follow the link i get the page i expect with the favicon.ico in the url address, but i really wonder if the live session is actually seeing that same thing in his browser url bar.
I also noticed some double sessions that i think may be related to this behaviour, but at this time i am not sure, i'll update if i have more relevant info.

on the suggestions bit i have one more consideration for your documentation. on the rubik link http://wiki.rubikintegration.com/zen...www_and_nonwww it says
RewriteCond %{HTTP_HOST} ^example\.

I believe in that example it should read
RewriteCond %{HTTP_HOST} ^example\.com

or it gets rewritten incorrectly?

cheers yellow,
really appreciate your input, thanks a lot.

The favicon mishap can be explained like this:
Look at the link of the icon in your html page source, you will see it uses relative link. Now when you are under site.com/blah/blah2 and you use relative link like that then it can be interpreted that the favicon image is under "blah2" folder.

Since we already set the base href, this should not happen, it's weird that it still happens from time to time on your site, but again this is not a bug. I can assure 100% that this has no effect on what search engine actually crawl. Another way to solve this would be using an absolute link for the favicon (like http://www.site.com/favicon.ico), dont forget that you need to use https in https pages.

Regarding the rewrite condition on the wiki, it does work as is. You can append the "com" if you want to.

Regarding session, it's just like ssl cert thing I mentioned, www and nonwww are treated differently.

[nagelkruid]

The favicon mishap can be explained like this:
Look at the link of the icon in your html page source, you will see it uses relative link. Now when you are under site.com/blah/blah2 and you use relative link like that then it can be interpreted that the favicon image is under "blah2" folder.

Since we already set the base href, this should not happen, it's weird that it still happens from time to time on your site, but again this is not a bug. I can assure 100% that this has no effect on what search engine actually crawl. Another way to solve this would be using an absolute link for the favicon (like http://www.site.com/favicon.ico), dont forget that you need to use https in https pages.

Regarding the rewrite condition on the wiki, it does work as is. You can append the "com" if you want to.

Regarding session, it's just like ssl cert thing I mentioned, www and nonwww are treated differently.

yep, both i have to agree on, i also noticed that the occurences seem to have gone down significantly, maybe this was somehow related to the gclid, although i can't put that together really... we do have regular clickthroughs from adwords, but anyway, lets give it a rest.

My major concern was not so much with what the search engines crawl but with what the users see/experience, i don't want them to click out of my page because they get a wrong experience.

the rewrite i got mixed up with another one as we are also running subdomains like webmail.mysite.nl but you're right, for a basic redirect that will do just fine.

Ok, off to bed now, seen enough for a day, cheers.

[ttco]

PM me your ftp info, it will be just way faster for me to change the files for you.

Hi,

Upon install of SSU, I'm getting the same chain of error messages that mtechama got: PHP Parse Error described in post #1112 (running PHP4, so changed file names as directed); then PHP Fatal Error described in post #1120 (installed and ran debug (learned nothing new)), now just loading header as described in post #1116, or occasionally, header with the fatal error message below. I am a newbie, but I've been over this about a dozen times, and can't figure out what I'm missing. Please help!

Note: I tried to PM ftp info, but storage limit is exceeded.

[yellow1912]

Hi,

Upon install of SSU, I'm getting the same chain of error messages that mtechama got: PHP Parse Error described in post #1112 (running PHP4, so changed file names as directed); then PHP Fatal Error described in post #1120 (installed and ran debug (learned nothing new)), now just loading header as described in post #1116, or occasionally, header with the fatal error message below. I am a newbie, but I've been over this about a dozen times, and can't figure out what I'm missing. Please help!

Note: I tried to PM ftp info, but storage limit is exceeded.

If you get the 2.9.6 version from my signature, it's the version that has file names already changed for php4 users.

Anyhow, can you post the fatal error here?

[ttco]

If you get the 2.9.6 version from my signature, it's the version that has file names already changed for php4 users.

Anyhow, can you post the fatal error here?

Here it is: Fatal error: Call to undefined function: registerarray() in /hsphere/local/home/ttco2006/tinytowntrading.com/includes/classes/ssu/languages/default.php on line 8

[yellow1912]

Here it is: Fatal error: Call to undefined function: registerarray() in /hsphere/local/home/ttco2006/tinytowntrading.com/includes/classes/ssu/languages/default.php on line 8

If you open that file, do you see something like this:

$this->registerArray($params); 

(the "A" is in upper-case)

[ttco]

Yes. Here's the entire file:

<?php
// note: we can later move part of this function into sub-functions, which we can store in the base class.
require('language.php');
class SSULanguage extends SSULanguageBase{
var $registry;

function parse_name($name, $params){
$this->registerArray($params);
// Remove short words first
if(($word_length = $this->registry('minimum_word_length')) > 0){
$name_parts = explode(' ', $name);
foreach($name_parts as $key => $value)
if(strlen($value) < $word_length) unset($name_parts[$key]);
$name = implode($this->registry('name_delimiter'), $name_parts);
}

// trim the sentence
if ($this->registry('max_name_length') > 0 && (strlen($name) > $this->registry('max_name_length'))){
preg_match('/(.{' . $this->registry('max_name_length') . '}.*?)\b/', $name, $matches);
$name = rtrim($matches[1]);
}

// we replace any non alpha numeric characters by the name delimiter
$name = str_replace(array(' ', '\'', '/', '\\', '"', '.', ':', '@', '_', '-', '?', '&', '='), $this->registry('name_delimiter'), $name);

// remove excess $this->registry('name_delimiter')
$name = $this->removeDelimiter($name);

// remove trailing _
$name = strtolower(trim($name, $this->registry('name_delimiter')));
return urlencode($name);
}
}