Jump to content
Wanze

SeoMaestro

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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 😂

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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!

Share this post


Link to post
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 ...

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
10 hours ago, tires said:

/site/templates/

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

/site/ready.php

  • Like 1

Share this post


Link to post
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!

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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 🙂

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...