SeoMaestro

[markus_blue_tomato]

@Wanze haha awesome - I had checked the sitemap generation in the module config but I don't use it and the path is not writeable.

after upgrading I got the error message and unchecked it. now my pw adminpanel runs 100 times faster.... ?

and I thought the slowness would be normal with this amount of fields/templates/pages ?

[B3ta]

9 minutes ago, Markus (Blue Tomato) said:

@Wanze haha awesome - I had checked the sitemap generation in the module config but I don't use it and the path is not writeable.

after upgrading I got the error message and unchecked it. now my pw adminpanel runs 100 times faster.... ?

and I thought the slowness would be normal with this amount of fields/templates/pages ?

Seems like I'm having the same issue and i couldn't trace what's going wrong. 

It seems like i'm getting an error once I'm trying to open the SEO field 

[Wanze]

19 minutes ago, B3ta said:

Seems like I'm having the same issue and i couldn't trace what's going wrong. 

It seems like i'm getting an error once I'm trying to open the SEO field 

You are most likely facing this core bug, which should be fixed by now: https://github.com/processwire/processwire-issues/issues/979
Check some of the replies on the previous page, others have mentioned the same error - should be gone if you update ProcessWire.

Cheers

[Wanze]

42 minutes ago, Markus (Blue Tomato) said:

@Wanze haha awesome - I had checked the sitemap generation in the module config but I don't use it and the path is not writeable.

after upgrading I got the error message and unchecked it. now my pw adminpanel runs 100 times faster.... ?

and I thought the slowness would be normal with this amount of fields/templates/pages ?

Uups, sorry about that. I did not think about this issue and also missed to handle the "error" case. ?So in your case, the module was generating the sitemap on every request. At least it did not affect the frontend ?Kudos to @teppo for bringing this up! ?

Cheers

[Tyssen]

I've upgraded PW to 3.0.141 and the module to 0.9.0 but still get the same error I reported on the previous page when accessing a page which has the field in its template.

[markus_blue_tomato]

10 hours ago, Wanze said:

Uups, sorry about that. I did not think about this issue and also missed to handle the "error" case. ?So in your case, the module was generating the sitemap on every request. At least it did not affect the frontend ?Kudos to @teppo for bringing this up! ?

Cheers

yes, the frontend was not affected ?

[Wanze]

10 hours ago, Tyssen said:

I've upgraded PW to 3.0.141 and the module to 0.9.0 but still get the same error I reported on the previous page when accessing a page which has the field in its template.

The commit which fixes the mentioned issue is not included in PW 3.0.141. You need to get the latest version from the "dev" branch or make sure that you include the code of this commit.

[Tyssen]

13 hours ago, Wanze said:

The commit which fixes the mentioned issue is not included in PW 3.0.141. You need to get the latest version from the "dev" branch or make sure that you include the code of this commit.

Actually it is. I've just checked wire/core/Fields.php and the added lines from the commit you linked to are already there.

[tires]

Great Module!

But i have two little issues.

1. I use the module on a german website were there are "umlaute" in the meta description. Although the whole page has UTF8 encoding, the meta description includes some "ä" etc.

2. I don't wan't to have the

<meta name="generator" content="ProcessWire">

on this special website. Is there a way to remove this?

[Juergen]

On 4/19/2019 at 10:19 PM, Wanze said:

$wire->addHookAfter('SeoMaestro::renderMetatags', function (HookEvent $event) { $tags = $event->arguments(0); $group = $event->arguments(1); if ($group === null) { unset($tags['meta_generator']); $event->return = $tags; } });

@tires This is the hook to remove the unwanted generator meta tag.

Best regards

[tires]

1 hour ago, Juergen said:

@tires This is the hook to remove the unwanted generator meta tag.

Best regards

Thanks!
Can you give me a hint where i got to add this code?

[Wanze]

On 10/4/2019 at 1:43 AM, Tyssen said:

Actually it is. I've just checked wire/core/Fields.php and the added lines from the commit you linked to are already there.

Quote

Call to undefined method stdClass::getArray()
107:$formManager->populateValues($form, $pageValue->getArray());

@Tyssen

 I just realized that you are having a different issue. For some reason, the module fails to deserialize a correct SeoMaestro page value object. Does this happen for every page?

If you have xdebug installed, you would set a breakpoint here and check what happens during the request: https://github.com/wanze/SeoMaestro/blob/master/FieldtypeSeoMaestro.module.php#L54
Although I cannot see how the code would return anything other than a PageFieldValue object, which means that somewhere this object gets casted to a "stdClass". Are you using any hooks which could produce this problem?

Also: Can you check the contents of your database row for the SeoMaestro field and the page where this error occurs?

Cheers

[Wanze]

2 hours ago, tires said:

Great Module!

1. I use the module on a german website were there are "umlaute" in the meta description. Although the whole page has UTF8 encoding, the meta description includes some "ä" etc.

@tires

Thanks!

The meta tags need to be HTML encoded because they are rendered inside HTML tags. This is not an issue, the tags will appear correctly in Google. The "ä" you are seeing in the source code is not related to the character encoding, it is just a character being HTML encoded.

Cheers

[Juergen]

3 hours ago, tires said:

Can you give me a hint where i got to add this code?

Put this code inside your ready.php which you will find inside your site/templates/ folder. If there is no such a file then create one (site/templates/ready.php)

[tires]

On 10/7/2019 at 5:37 PM, Juergen said:

Put this code inside your ready.php which you will find inside your site/templates/ folder. If there is no such a file then create one (site/templates/ready.php)

I added this code:

<?php
$wire->addHookAfter('SeoMaestro::renderMetatags', function (HookEvent $event) { 
	$tags = $event->arguments(0); 
	$group = $event->arguments(1); 
	if ($group === null) { 
		unset($tags['meta_generator']); $event->return = $tags; 
	} 
}); 

to a file called ready.php that is placed in the /site/templates/ directory.

Without any effect. The

<meta name="generator" content="ProcessWire">    

is still there ...

Any ideas?

Thanks an best regards!

[tires]

On 10/7/2019 at 2:06 PM, Wanze said:

@tires

Thanks!

The meta tags need to be HTML encoded because they are rendered inside HTML tags. This is not an issue, the tags will appear correctly in Google. The "ä" you are seeing in the source code is not related to the character encoding, it is just a character being HTML encoded.

Cheers

Thank you!
I didn't know that ...

[Lutz]

On 10/7/2019 at 2:06 PM, Wanze said:

@tires

The meta tags need to be HTML encoded because they are rendered inside HTML tags. This is not an issue, the tags will appear correctly in Google. The "ä" you are seeing in the source code is not related to the character encoding, it is just a character being HTML encoded.

@Wanze Hm, I wouldn't like to see german umlauts encoded and it shouldn't be necessary, if we use UTF-8. In many cases it should be sufficient to use htmlspecialchars with ENT_QUOTES here. If you see a need to use htmlentities instead, you could flag with ENT_XML1, to avoid encoding äöüß.

[wbmnfktr]

10 hours ago, tires said:

/site/templates/

Place the ready.php into /site/ and it should work.

/site/ready.php

[tires]

On 10/10/2019 at 2:04 AM, Lutz said:

@Wanze Hm, I wouldn't like to see german umlauts encoded and it shouldn't be necessary, if we use UTF-8. In many cases it should be sufficient to use htmlspecialchars with ENT_QUOTES here. If you see a need to use htmlentities instead, you could flag with ENT_XML1, to avoid encoding äöüß.

So, is there a way to not encode german umlauts?

On 10/10/2019 at 11:15 AM, wbmnfktr said:

Place the ready.php into /site/ and it should work.

/site/ready.php

Ah! Thanks!
It Works!

[Wanze]

On 10/10/2019 at 2:04 AM, Lutz said:

@Wanze Hm, I wouldn't like to see german umlauts encoded and it shouldn't be necessary, if we use UTF-8. In many cases it should be sufficient to use htmlspecialchars with ENT_QUOTES here. If you see a need to use htmlentities instead, you could flag with ENT_XML1, to avoid encoding äöüß.

I agree. Could you open an issue on GitHub? Should be easy to integrate this in the next release.

Quote

So, is there a way to not encode german umlauts?

@tires

Not in the current version. Technically there is a way, but it feels hacky. You'd need hook after SeoMaestro::___renderSeoDataValue() and then entity decode and encode the value again.

See: https://github.com/wanze/SeoMaestro#___renderseodatavalue

Cheers

[psy]

1. I'm getting the following error on a number of sites running PW3.0.142+

Failed to generate the XML sitemap

Even though the API should have write access to the site root (unless something has changed in .htaccess?). I know others have raised this issue but I cannot figure it out.

2. The module default values do not parse PW vars while per page SeoMaestro fields do, eg in the field default Meta section:

literally displays {title} in the browser tab. However if on a page seo override I uncheck the Inherit default value checkbox and enter:

on page output, it correctly parses headline (1st priority) or page title (2nd priority) text in the browser tab.

Help to fix both issues much appreciated.

 

[teppo]

Hey @psy. Just a heads-up that I've merged your post to existing seomaestro support thread. Hopefully someone here can help with the issues you're experiencing ?

[psy]

Thanks @teppo realised I'd posted in the wrong forum and didn't know how to change it

[neophron]

Hi,

I noticed the following problem:
Processwire 3.0.123 and seomaestro 0.9.0, the step after the installation, where you can enable the sitemap generation. After hitting »submit« I got this error:

Session: Failed to generate the XML sitemap. Make sure that "/www/htdocs/.../pw-3-0-123" is writeable.

This happens in two different PW installations.
After replacing the module with the 0.6.0 version, everything works fine.

[titanium]

11 hours ago, neophron said:

Hi,

I noticed the following problem:
Processwire 3.0.123 and seomaestro 0.9.0, the step after the installation, where you can enable the sitemap generation. After hitting »submit« I got this error:

Session: Failed to generate the XML sitemap. Make sure that "/www/htdocs/.../pw-3-0-123" is writeable.

This happens in two different PW installations.
After replacing the module with the 0.6.0 version, everything works fine.

No solution, but I guess there is definitely something broken. I'm getting error messages like the following on multiple servers of mine:

Fatal error: Method SeoMaestro\PageFieldValue::__toString() must not throw an exception, caught ErrorException: chdir(): open_basedir restriction in effect. File(/var/www/php-fcgi-scripts/web366) is not within the allowed path(s)

Somebody mentioned that earlier in this thread, but no solution was proposed (the error went away automagically in that case).