527 replies to this topic

[FWR Media]

burt, on 03 December 2009 - 11:32 PM, said:

Another linked anomaly - the "reviews" button takes the usual form of URL (when the page is accessed from the shopping cart).  Perhaps make it an option in the admin area, to return from cart sans attribs?

I don't understand the reviews thing, where does reviews have a normal uri (except for reviews write which is intentional)?

[burt]

Rob do as above - put a product in cart (with attributes).  Link back from the cart link to the same product (this will be via a normal URL).  Now mouseover the reviews button at the bottom of the product description...

[FWR Media]

burt, on 04 December 2009 - 12:05 PM, said:

Rob do as above - put a product in cart (with attributes).  Link back from the cart link to the same product (this will be via a normal URL).  Now mouseover the reviews button at the bottom of the product description...

Yes I see what you mean now Burt. It's the same thing .. seo uri will not be produced where there are attributes in the products_id .. bots shouldn't have products in cart so no SEO issue.

I suppose an admin setting could be put in place to suppress attributes and therefore produce seo uri in these cases but I struggle to see the benefit.

[FWR Media]

There is now a dev package of USU5 PRO available to test .. it is a super fast "drop on top" installation.

Set up a fresh osCommerce RC2a ( 3mins )
Drop the USU5 PRO files on top ( 1 min )

Done.

If you would like to test this for me please post here and I will pm you a download link (not adding here as a contribution until initial testing is done).

Rob

[toyicebear]

can do a test if needed...

[FWR Media]

toyicebear, on 05 December 2009 - 12:27 PM, said:

can do a test if needed...

Thanks Nick have sent the download address.

[mikeman]

Thanks for the link.
I'm gonna check it out.

[mikeman]

Interesting concept this splitting of things
just unlike the solution of the crazy dudes who made the zend optimizer a requirement.
I kind of miss the language switching of a product, though.
Just a little question.
Is it possible to implement a switching between installed languages of currently displayed products/categories,
instead of refering to index.php with the wanted language?

[FWR Media]

mikeman, on 05 December 2009 - 09:07 PM, said:

Interesting concept this splitting of things
just unlike the solution of the crazy dudes who made the zend optimizer a requirement.
I kind of miss the language switching of a product, though.
Just a little question.
Is it possible to implement a switching between installed languages of currently displayed products/categories,
instead of refering to index.php with the wanted language?

I know what you mean and very much appreciate your testing and your feedback, this was not a priority in development, if it becomes an issue I'll have to look at it but the focus was in seperating the languages for seo purposes.

Edited by FWR Media, 05 December 2009 - 09:41 PM.

[FWR Media]

Thanks for the feedback so far.

I have no reports of any issues on *nix installations.

On Windows both Burt and Perfectpassion/Tomh report the following: -

What should be ..

http://www.mysite.com/usu5.1/index.php/movies-c-3

Is showing ..

http://www.mysite.com/usu5.1/index.php-c-3

Also what should be ..

http://www.mysite.com/usu5.1/index.php/movies/action-c-3_10

Is showing ..

http://www.mysite.com/usu5.1/index.php//action-c-3_10

Quite why the movies text is missing and why ONLY for this one category at the moment I haven't a clue as I have no access to a Windows server.

I'm hoping for further feedback from Windows testers as to exactly what is causing this anomaly.

[FWR Media]

SOLVED: issue with missing "movies".

Thanks to PerfectPassion( TomH ) for finding and solving this.

It was not a Windows issue it was an issue with PHP versions less than 5.2.4.

includes/modules/ultimate_seo_urls5/abstracts/aDatamap.php

Find ..

	  $link_text = preg_replace( "@[\s\v]+@", '-', $link_text );

Replace with ..

	if ( PHP_VERSION <= '5.2.3' ) {
	  $link_text = preg_replace( "@[\s]+@", '-', $link_text );
	} else {
	  $link_text = preg_replace( "@[\s\v]+@", '-', $link_text );
	}

PHP 5.2.4 upgraded the version of PCRE to 7.2 prior to which \v doesn't work.

Edited by FWR Media, 06 December 2009 - 12:09 PM.

[FWR Media]

Who is still testing this please?

[mikeman]

Mod rewrite links work great so far. No issues here, thanks.
Just one thing: is it possible to restore the "$lng->get_browser_language();" functionality? I always get the default language shop.

[FWR Media]

mikeman, on 08 December 2009 - 01:26 PM, said:

Mod rewrite links work great so far. No issues here, thanks.
Just one thing: is it possible to restore the "$lng->get_browser_language();" functionality? I always get the default language shop.

Well that code has become somewhat irrelevant because (standard osC settings)..

If you land on index.php the language is English

If you land on index.php/de the language is German

If you land on index.php/es the language is Spanish

The only way to re-introduce language by browser language would be for the script to do a header redirect which is dangerous.

[mikeman]

But I think it's important for german/spain customers (with their german/spain browsers)
who reach you via mysite.com/index.php in expectation of their own lang.
They get default-english displayed and must (intricately) change the language setting.
I think the a default solution is rather somehing for owners who want to serve a particular country.

Regards

[FWR Media]

mikeman, on 08 December 2009 - 02:24 PM, said:

But I think it's important for german/spain customers (with their german/spain browsers)
who reach you via mysite.com/index.php in expectation of their own lang.
They get default-english displayed and must (intricately) change the language setting.
I think the a default solution is rather somehing for owners who want to serve a particular country.

Regards

Yes it's a valid point and thanks for testing.

What should the script do if a german user who is in Spain with a spanish browser lands on index.php/de?

[mikeman]

There was once (if I get you right) a similar problem with annoyed
owners who had e.g. german customers (only) that surfed with a spanish browser
or had the english firefox version and therfore got the page in spanish or english.
They implemented a set_language() instead of get_browser_language() and were happy ever after.

But the normal case is that
the shop checks whether it can get the language out of the browser-data.
If yes, the script displays the page with the corresponding language or
the script can't conclude that and gets the default language-setting.

I hope USU pro doesn't overwrite it.

Regards

[FWR Media]

mikeman, on 08 December 2009 - 04:00 PM, said:

There was once (if I get you right) a similar problem with annoyed
owners who had e.g. german customers (only) that surfed with a spanish browser
or had the english firefox version and therfore got the page in spanish or english.
They implemented a set_language() instead of get_browser_language() and were happy ever after.

But the normal case is that
the shop checks whether it can get the language out of the browser-data.
If yes, the script displays the page with the corresponding language or
the script can't conclude that and gets the default language-setting.

I hope USU pro doesn't overwrite it.

Regards

No USU5 overwrites nothing .. but currently if multi languages are on then the multi language system over rides it.

[FWR Media]

I have thought some more about the "browser language" thing and the more I think about it the more I think it cannot (and shouldn't) work like that.

Obviously I am open to thoughts and suggestions which is what this beta test is for so please feed back your thoughts.

Why it can't work.

The whole idea of a multi language system is that Google (and friends) can index the site seperately as the different shop languages. What this means is that there would be indexed, as an example a url like ..

www.mysite.com/de/my-great-product-32.html

Now when the user clicks on that link it MUST open the German page as indexed it can't "decide to change it" based on the users browser.

Remember Google do human as well as robot examination, showing the human examiner a different page to a bot leads to penalisation .. I just can't see it as a good idea.

[mikeman]

FWR Media, on 08 December 2009 - 05:20 PM, said:

No USU5 overwrites nothing ..

Of course not. Sorry, I ment it in an overriding way.

FWR Media, on 08 December 2009 - 05:20 PM, said:

but currently if multi languages are on then the multi language system over rides it.

That's sad. I don't think I could do without it.
thanks

Edited by mikeman, 08 December 2009 - 06:51 PM.