Our site run currently with the SEO mod SimpleSMF on a testphase.
Please tell us, if you see any error.

Fel

Hi Fel

I notice the .html extension added to the urls I visit a link on your site.

Everything seems to work OK to me.

yes .. that's true and correct 

Fel

I have stopped the test with SimpleSEF, because it produce a lot of errors and many links don't work correct.

And it looks like the developer is not willing or able to follow his program to the requirements that we place on good software, too. Thus, the matter died for us.

Read the messages up from here:
http://www.simplemachines.org/community/index.php?topic=352351.msg2409619#msg2409619

Fel

I have tested the v1.0.2 of SimpleSEF .. but I see the same problems as before.

Dynamic created url like url/index.php?theme=num and url/index.php?language=langname don't work, the theme request ends in a error.
Singepage requests they have a dot in the pagename also don't work..

To get this to work, it's need two small changes, but we don't offer these.
Why not? Yea .. good question .. and the answer:
I see, that Slammeddime have added special codes for SimplePortal...

We see that with very interest and we get the consequences of this ingnorance ...

Fel

hmmm...what do the others can...what Feline not can do by her self

Feline i think you should do your own seo-mod for your excelent portal and blog

*lol* ... no, no .. we have enough to do with the next major release of portamx.
# categories and articles
# designed front page
# download manager
and mutch more ...
I think, that is a long run 

Fel

yep,
i guess there are more important things than seo

is there a roadmap for the next major release?

yes, that is planned ...

Just wanted to add something here. We checked SSEF very very thoroughly prior to installation on SimpleDesk.net, in light of all your comments, and while yes, there was an issue with theme/language, that was fixed in 1.0.2 - and I can use ?theme=x just fine over on SimpleDesk.

In fact, the only issues we had were related to Project Tools, not to anything else.

That is not true!
The theme=x and language=lang don't work in SSEF 1.0.2 if the link is dynamically (with javascript) created.
You can simple test that with:

global $scripturl;
echo '
<form id="chgtheme" action="'. $scripturl .'" method="post"></form>
<script type="text/javascript"><!-- // --><![CDATA[
document.getElementById("chgtheme").action = "'. $scripturl .'?theme=1";
document.getElementById("chgtheme").submit();
// ]]></script>';

Same for language ..

And a legal request like url/index.php?my.page also don't work.
For this php bug there is an easy and simple solution that has no side effects on the functions SSEF.

Fel

1. Code doesn't work for me at all, just does nothing. In any case I'm not entirely sure what that's trying to prove. I note that at no point was this mentioned in the original report.

If you have it forming a proper URL it should be diverting through the 301 redirection anyway, which suggests to me that some other element of configuration may be incorrect.


2. As addressed in the SSEF thread, it may be a valid URL in itself, but PHP doesn't entirely consider it valid - and never has.

http://us2.php.net/manual/en/language.variables.external.php

QuoteDots in incoming variable names

Typically, PHP does not alter the names of variables when they are passed into a script. However, it should be noted that the dot (period, full stop) is not a valid character in a PHP variable name. For the reason, look at it:

<?php
$varname.ext;  /* invalid variable name */
?>
Now, what the parser sees is a variable named $varname, followed by the string concatenation operator, followed by the barestring (i.e. unquoted string which doesn't match any known key or reserved words) 'ext'. Obviously, this doesn't have the intended result.

For this reason, it is important to note that PHP will automatically replace any dots in incoming variable names with underscores.

So while, yes, you can use index.php?my.page as a legal URL in and of itself, what happens if you ever have index.php?my_page as well? There are times this collision can occur, and as a safeguard, SSEF does not support this method. I also cannot name any other PHP application that supports this method, for this very reason.


EDIT to add: I pointed SlammedDime in this direction, the snippet worked for him just fine. So I possibly did something that broke the snippet when I tried it - but the correct URL was in the generated page source and handled correctly for him.

Quote from: Arantor, 9 years ago
1. Code doesn't work for me at all, just does nothing. In any case I'm not entirely sure what that's trying to prove. I note that at no point was this mentioned in the original report.

As I say .. the theme id is added dynamically in a javascript variable like
document.getElementById("chgtheme").action = "'. $scripturl .'?theme=" + themeid;

The result is, that SSEF the coded as url/theme/1.
Same on language:
document.getElementById("chglang").action = "'. $scripturl .'?language=" + langname;
is code as url/language/english

Fel

Isn't that was what was fixed in 1.0.2, meaning it should be generating url/theme,1/ style URLs?

Definitely using 1.0.2?

Yes, here running SSEF 1.0.2 (see attached image)

And the problem, we see, is the url rewrite .. SSEF see the $scripturl  and the theme=, the themeid is a javascript variable, so the url result is url/theme/id, that must url/theme,id.
the one and only way to get this to work:
add this before // handle unknown variables

//> add by PortaMx
elseif($url_array[0] == 'language' || $url_array[0] == 'theme')
{
$querystring[$url_array[0]] = $url_array[1];
array_shift($url_array);
array_shift($url_array);
}
//>


also the special portmax page reques can handled very simple ..
find:

 parse_str(!empty($url_parts['query']) ? $url_parts['query'] : '', $params);

replace with:

//> modify by PortaMx
 if(!empty($url_parts['query']))
 {
   if(strpos($url_parts['query'], '=') !== false)
   parse_str($url_parts['query'], $params);
   else
     $params[$url_parts['query']] = '';
 }
//>


I have add this small changes and all works perfect.
The 301 redirect we can't use, because the theme and language change itself make a redirect to to url on wich the request started, the redir url is a $_POST value ..

Fel

[attachment deleted by admin]

More problem I found and fixed ...

1) If you had enabled SMF Search engine friendly URLs, exist url (in posts) don't work.
find:

// Get the query string of the passed URL
$params = array();
$url_parts = parse_url(str_replace(array(',', '&', ';'), array('=', '&', '&'), $url));

replace:

// Get the query string of the passed URL
$params = array();
//> modify by PortaMx
$url_parts = parse_url(str_replace(array(',', '&', ';'), array('=', '&', '&'), str_replace($boardurl .'/index.php/', $scripturl .'?', $url)));


2) I see hundreds of url parse error in the apache error log.
I think this is a good fix ...
find:

// Parse the url
$url_parts = parse_url(str_replace($boardurl, '', $_SERVER['REQUEST_URL']));
if (empty($url_parts['path']) || $url_parts['path'] == '/')
return;

replace:

// Parse the url
//> modify by PortaMx
if(strpos($_SERVER['REQUEST_URL'], $boardurl) !== false)
{
$url_parts = parse_url(str_replace($boardurl, '', $_SERVER['REQUEST_URL']));
if (empty($url_parts['path']) || $url_parts['path'] == '/')
return;
}
else
return;


these fixes runs here.

Fel

would be nice for others to know in wich files you did all the changes

We make a modification for SSEF 1.0.2 and PortaMx v0.971-2.
This will be developed today .. 

Fel

Quote from: feline, 9 years ago
*lol* ... no, no .. we have enough to do with the next major release of portamx.
# categories and articles
# designed front page
# download manager
and mutch more ...
I think, that is a long run 

Fel

I was looking for SimpleSEF and google got me here and was happy to see those

As far as I have seen  on mod's test site it doesnt have any affect on page descriptions. Wont that affect google indexes ?

This does not work for me, ? Returns 500 server error. I need to look at the error logs but can't do that until tomorrow. Mod Rewrite is supported.

Ok, figured it out.

For Godaddy and maybe some other host your going to have to have your .htaccess like this instead.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) /index.php

Almost the same code but a ^ and a / inserted. 

Well I guess this would be a integration bug.

I have hidden blocks on my site like ^arcade, but if I set it up this way to hide on a certain area on the site, it hides it everywhere. It somehow has to do with SimpleSEF.