Jump to content

SeoMaestro


Wanze

Recommended Posts

@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 😀

  • Like 1
Link to comment
Share on other sites

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 

Screenshot%202019-10-02%2022.16.21.png?d

Link to comment
Share on other sites

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 

Screenshot%202019-10-02%2022.16.21.png?d

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 😂

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 "&auml;" 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 "&auml;" you are seeing in the source code is not related to the character encoding, it is just a character being HTML encoded.

Cheers

  • Like 2
Link to comment
Share on other sites

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)

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 "&auml;" 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 ...

Link to comment
Share on other sites

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 "&auml;" 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 äöüß.

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

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:

1233989935_Screenshot2019-10-2920_25_21.png.c522e052b63f4a5ea46db99ab667da65.png

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

1858803940_Screenshot2019-10-2920_29_18.png.590bed6c44c221714da658cd36f13de6.png

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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). 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...