og:url wrong about cs_seo HOT 16 CLOSED

Hi, We didn't change anything in the canonical settings since version 1.5.0. But there is a fallback setting in the typolink.

If the current page is not really translated, so that only the content_fallback is shown, the sys_language_uid is set to zero. We will proof this.

As a quick workaround you can configure realurl, that a L=0 param will not be shown in the URL:

'preVars' => array ( '1' => array ( 'GETvar' => 'L', 'valueMap' => array ( // Define all languages, except the default language 'en' => '1', ), 'noMatch' => 'bypass', ), ),

from cs_seo.

I have updated 2 typo3 pages and both now have this new canonical and og url.

We have overwrite this now in typoscript lib.currentUrl

from cs_seo.

As I said we have configured this, for the case that a content_fallback page is shown. So the canocial should refer to the default language.

If your page should not show L=0 in the URL then you could configure realURL correctly, e.g. with 'noMatch'=>'bypass'.

We will check if it is possible to force the default language for content_fallbacks without setting the L parameter to zero. Maybe we can exclude the param if it is zero.

To edit the lib is also a workaround. How did you modify the lib?

from cs_seo.

We had overwrite it in additionalParams that was a short fix ;-)

But after your comment we improved the realurl configs, this is the better way.

Maybe you can make a hint in the docu, because non multilanguage pages are default have L=0 or the corresponding realurl value in the url, this could be bad for the google index if you don't realize it after the update.

from cs_seo.

This issue took me long time to find and solve. I also discussed L=0 with the developer of RealURL, because there is something extra needed there. Simply nomatch => bypass doesn't work for me. And more also, RealURL shouldn't fix issues that are invoked by other extensions.

So in lib.currenUrl.ts I commented this:

		//additionalParams.required = 1
		//additionalParams.data = page:_PAGES_OVERLAY_LANGUAGE
		//additionalParams.ifEmpty = 0
		//additionalParams.wrap = &L=|

That wasn't enough.

In HeaderData.php I changed this line 289:

    $canonicalTypoLinkConf['additionalParams'] = '&L=' . $lang;

into

if($lang > 0) {
 $canonicalTypoLinkConf['additionalParams'] = '&L=' . $lang;
}

Now I have my result. Perhaps you can update the source like this? Or with another (better) solution.

from cs_seo.

Hey. Thanks for your report. But if you don't configure realURL correctly it allways will be possible that you have two versions of urls, one with and one without L=0. Even if you don't use cs_seo. This could also happen if you use a language switch or redirection etc. It is also not a bug in realURL. You can avoid this behaviour. A full example is shown here https://docs.typo3.org/typo3cms/extensions/cs_seo/Administrator/TroubleShooting/Index.html it is simple to setup. Does that work for you?

from cs_seo.

We have to force L=0 for the href-lang URLs. If you crop the L param in another language then the default lanugage, the current language will be added automatically. So you can not link to the default language without L=0.

from cs_seo.

Hi, thanks for your response. The developer of RealURL knows what he's talking about as well. So you should convince Yuri on this... good luck with that ;-)

Your proposed solution doesn't work for me.

The issue occurs if we have no multiple languages. We simply don't need the L=0 in case there's just one language. But it's still generated as canonical and og:url. I don't know how it behaves in a multi lingual setup, but my guess is that we still don't need L=0 there, but then your solution might be right.

Now the question is actually, use a bypass which is not what I think is right in terms of "better not use a hack", or adapt the code with a harmless if-statement, and comment that setup lines by default. (if my solution is correct, that is)

Bottomline: can TYPO3 integrators understand the issue and solve it. I think you can document it easily for them.

The problem was generated by an SEO tool that my customer uses. They shouldn't do that. But anyway you look at it, it keeps many people happy if you solve it in your code, where it should be solved in my opinion.

from cs_seo.

Hi. As I said it is no problem of realURL. On the other hand I really would like to solve this. But as I described it is not possible to force the default language in an other way. Do you have a solution for this?

from cs_seo.

I will add a link here https://docs.typo3.org/typo3cms/extensions/cs_seo/Administrator/Installation/Index.html to the trouble shooting section, so that the integrator should know about that issue

from cs_seo.

Indeed, you didn't say it's a RealURL problem. Sorry if I left the impression. But that RealURL is the best place to solve the issue. I tried that approach, but it's not working in either way.

To solve it, for instance, it would be nice if RealURL had a checkbox in the extension configuration defining "no multi language".

May be cs_seo can do something with that? As long as there is only one language used (the default for that domain) perhaps you can pass many issues with a config setting for the domain. It's not enough to just count the defined languages, because we may have a multi domain setup.

from cs_seo.

Something like:

'preVars' => [ [ 'GETvar' => 'L', 'valueMap' => [ 'de' => '1', ], 'noMatch' => 'bypass', ] ],

Did the job for me :)

from cs_seo.

Meanwhile, I found out that parameters like "?MP=5820-6612" get also attached in the navigation.

from cs_seo.

I don't know what is the problem to configure realURL this way?

from cs_seo.

For the "?MP=5820-6612" issue: you can exlude parameters in the lib.currentUrl

lib.currentUrl.typolink.addQueryString.exclude := addToList(M)

If you got further question on this issue, please open a new issue

from cs_seo.

The RealUrl hint does not work for me. Maybe because I don´t use languages. For me only this helped:
lib.currentUrl.typolink.additionalParams.append >

from cs_seo.