SeoMaestro

[psy]

On 11/1/2019 at 7:33 AM, titanium said:

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

Problem didn't go away for me. It still exists and no solution found. Turned off sitemap.xml generation to lose the error message. Still hoping for a fix

[teppo]

2 hours ago, psy said:

Problem didn't go away for me. It still exists and no solution found. Turned off sitemap.xml generation to lose the error message. Still hoping for a fix

Do you have a SEO field (FieldtypeSeoMaestro) added to at least one of your templates? I can't remember if this was always a requirement, but without that the module won't generate a sitemap, and thus it will output that specific error message.

This error is a bit misleading: it recommends checking that the folder on disk is writable, but you'll get the same error even if you simply didn't have any items to add to the sitemap. What's happening here is basically that the module attempts to generate a sitemap with SitemapManager::generate(), which returns false if it fails to write the file, but also if there are no items to be found. Ping @Wanze – might be a good idea to add additional check for this ?

If you do have the SEO field and the write permissions are fine, I'd probably try debugging the sitemap generation code in the SitemapManager class, just to see if it's working as expected.

[psy]

Hi @teppo, yes had field named 'seo' of FieldtypeSeoMaestro assigned to a number of templates and publicly viewable pages

[teppo]

11 minutes ago, psy said:

Hi @teppo, yes had field named 'seo' of FieldtypeSeoMaestro assigned to a number of templates and publicly viewable pages

Well, this likely rules out the first issue I was thinking of.

There are still two possible explanations: either sitemap generation fails, or writing the sitemap file to the disk fails. I'm not particularly familiar with this module, so all I can suggest at this point would be dumping some debug data out of SitemapManager::generate() function; basically checking if the !count() statement is returning false (in which case there are no items, which in turn would warrant further investigation into why that would happen), or if it's the write operation that is failing.

You should also double-check that the path on disk (the root of your site, essentially) is writable for the user running Apache (often www-data, but could be something else, depending on your setup).

Edit: I installed SeoMaestro on a new site running the latest dev version, and everything worked as expected. I know this won't help much in this case, but at least I can confirm that the module should work, which means that the issue is likely somehow related to your environment, or the specifics of your site ?

Edited November 3, 2019 by teppo

[psy]

Thanks again @teppo. I tried a few things with my limited knowledge of Apache including changing root dir privileges to 777 (scary I know!) for testing purposes to see if the error message was correct. Didn't change anything so switched the root dir privileges back to PW preferred settings.

Obviously something is amiss and fairly certain it's not that SeoMaestro cannot create the file. I even saved a dummy sitemap.xml file (updated module prefs to same file name) in the root dir and still no luck. I've used this module before with success on other sites with earlier PW versions.

Problem reared its head with PW1.0.142+. Wondering if maybe latest .htaccess or other is affecting things? @Wanze?

[Wanze]

Hi @psy

The module does a pre-check if the folder of the sitemap is writeable (https://github.com/wanze/SeoMaestro/blob/master/SeoMaestro.module.php#L174-L181). If not, it should not attempt to create the sitemap at all. So I think that we can rule this error out. Thanks @teppo for the investigation and the hint regarding the misleading error message. I fixed it with the following commit: https://github.com/wanze/SeoMaestro/commit/3fc2835b4ea1956006a82b9f8363cb6f89b4f1f4. The module now throws an exception if the sitemap folder is not writeable. This allows to distinguish this error from other errors that could happen during the sitemap generation process. @psy If you update to the latest version on master, you should not see the misleading error message anymore.

Did you check the ProcessWire logs if they contain any errors? Also possibly check the PHP error logs on your webserver. My guess is that somehow an error happens during the sitemap generation process. Because this process is executed after the response has been sent back to the client, error messages are not that obvious. If you do not find any error messages, I'd suggest to downgrade ProcessWire to the latest version where things worked as expected. Do you have any SeoMaestro related hooks in place that could cause errors?
.htaccess changes should not have any effects on this module. If you can, try to debug what happens during the request, for example with xdebug (like Teppo suggested earlier).

Cheers

[Wanze]

On 10/31/2019 at 10:21 AM, 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.

Hi @neophron

Can you download the latest version of the master branch from GitHub and check if you still get this error? The error message was misleading. Before downgrading, did you check if the sitemap has been generated as expected?

[neophron]

 

I replaced your latest version from github. Now the sitemap generation works fine, but as soon as I'm editing a page, this error shows up in the backend/admin area:

WireDatabasePDO: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_seomaestro.structuredData_inherit' in 'field list'

This error appears only in pages with templates, where the seomeastro field is included.
Do you need more informations from my installation?

[Wanze]

34 minutes ago, neophron said:

 

I replaced your latest version from github. Now the sitemap generation works fine, but as soon as I'm editing a page, this error shows up in the backend/admin area:

WireDatabasePDO: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_seomaestro.structuredData_inherit' in 'field list'

This error appears only in pages with templates, where the seomeastro field is included.
Do you need more informations from my installation?

It seems like ProcessWire did not update the included FieldtypeSeoMaestro module to 0.9.0. Can you hit the "Refresh" button in the ProcessWire admin? This error should go away if the FieldtypeSeoMaestro module is updated to version 0.9.0 as well.

[neophron]

I refreshed the modules after I replaced the module. The error is still there. Check my screenshots.

[Wanze]

@neophron That's weird. I know why the error happens: The module introduced a new group "structured_data", which also needs a new column for each SeoMaestro field in the database. The following code should take care of this when the module is being updated: https://github.com/wanze/SeoMaestro/blob/master/SeoMaestro.module.php#L64-L68
For some reason in your case, this did not happen. Can you try to execute the code above anywhere in a template? Or temporarily copy it into the module's ready() method. This should update each database table and resolve the error you're seeing.

Cheers

[neophron]

1 hour ago, Wanze said:

@neophron That's weird. I know why the error happens: The module introduced a new group "structured_data", which also needs a new column for each SeoMaestro field in the database. The following code should take care of this when the module is being updated: https://github.com/wanze/SeoMaestro/blob/master/SeoMaestro.module.php#L64-L68
For some reason in your case, this did not happen. Can you try to execute the code above anywhere in a template? Or temporarily copy it into the module's ready() method. This should update each database table and resolve the error you're seeing.

Cheers

Now I took a different PW installation on a different server, I installed SeoMaestro the classic way, trough modules --> install.
I tested till now only the sitemap.xml generation and it works fine.

[neophron]

On 4/20/2019 at 3:48 PM, Peter Knight said:

@Peter Knight UPDATED: After a little more research, I have discovered that index, follow are the default for search engines and don't need to be specified so it appears as if your module is functioning as it should.

 

Hi Peter,
I just found your post: If I activate the options »Prevent search engines from indexing this page« and »Prevent search engines from following links on this page« see maestro will generate <meta name="robots" content="noindex, nofollow">.
The no existing of this meta-tag is equal to <meta name="robots" content="index, follow">. Is this correct?

 

[dragan]

36 minutes ago, neophron said:

The no existing of this meta-tag is equal to <meta name="robots" content="index, follow">. Is this correct?

yep

[adrian]

@Wanze - I am curious if you would be willing to adjust the inheritance model a little. I am looking to be able to have site editors set the OG image on the homepage and have it inherited by all other pages unless they specifically upload an image to another page. Currently the only way I can see to do this is to set the field's main default image to the URL of an image that is uploaded to the homepage, which means the editors need to explicitly name the image so the URL is always the same. I think it would be great if pages inherited values from their parent pages, rather than just directly to the field's default values.

Does that make sense and sound useful?

Thanks!

[sz-ligatur]

Hi adrian,

I had a similar situation, and found an editor friendly solution using hooks:

https://github.com/wanze/SeoMaestro/issues/8#issuecomment-486658463

Maybe that's a starting point?

[Wanze]

Hi @adrian

You could use the solution mentioned by @sz-ligatur

1. Setup an image field holding the OG image (og_image). Configure this field to use the image of the homepage as default value, if no image is set.
2. Use the placeholder {og_image} in SeoMaestro.

The meta tag should now output the image of the homepage unless content editors overwrite the OG image in a page.
Would this solution work for you? I think we'd introduce another level of complexity if the inheritance model includes the page tree and I'd rather keep it simple for now ?

Cheers

[Wanze]

Hi all,

I just released the first stable version (1.0.0). Decided to go stable because there have not been many bug reports. The module follows the SemVer specification: There won't be any breaking changes in the API for the 1 major version. Here's the changelog of the release: https://github.com/wanze/SeoMaestro/releases/tag/v1.0.0

Happy day ?

[adrian]

Thanks @sz-ligatur - that hook is very helpful.

@Wanze - the catch with the hook approach is that the FB preview doesn't show the correct image - is there an easy way to fix that? Thanks!

[Wanze]

On 11/21/2019 at 5:18 PM, adrian said:

Thanks @sz-ligatur - that hook is very helpful.

@Wanze - the catch with the hook approach is that the FB preview doesn't show the correct image - is there an easy way to fix that? Thanks!

The solution mentioned above does not use any hooks. ? I did not test it, but I'm positive that the image pulled from the home page appears in the preview.

[sz-ligatur]

@Wanze – congratulations for version 1.0.0 and a big thank you!

@adrian: i've got it working now to correctly display the og:image in admin view – below the hook with inheritance mode as follows: if page og:image is empty, travel up tree until there is one at closest parent, use this. If no og:image found until home use default og:image from settings-page (a special page for sitewide settings).

should go @ready.php 

/**
 * In addition to module SeoMaestro
 * if page has no og:image set, inherit from closest parent with given og:image
 * if no og:image is set in branch until home -> fallback to default og:image @settings-page 
 */

$this->addHookAfter('SeoMaestro::renderSeoDataValue', function (HookEvent $event) {
    $group = $event->arguments(0);
    $name = $event->arguments(1);
    $value = $event->arguments(2);

    $isAdmin = ($this->page->rootParent->id == 2);
    if ($isAdmin) {
        $page = wire('pages')->get(wire('input')->get->id);
    } else {
        $page = $event->wire('page');
    }

    $field = "og_image";    // used field for og:image 
                            // @config: one element or NULL if empty
                            // no default output if empty

    $configpage = "1049";   // holding site-wide default og:image (og_image here set as required)

    if ($group === 'opengraph' && $name === 'image') {
        
        bd('og image is: '.$value);
        bd('page is: '.$page->id);

        // do nothing if page has og:image
        if ($value !== "") return;

            $sitedefaultimage = wire('pages')->get($configpage)->getFormatted('og_image');

            //scenario 1: fetch default image assigned in field-settings (get formatted)
            // config field settings @og_image accordingly, what page to use if empty

            //scenario 2: inherit from next upper parent-page in tree with assigned image 
            // @config @og_image: no setting for default value

            $selector = "og_image.count>'0'";
            $option = $page->parent($selector);

            if ($option->id) {
                $value = $option->getFormatted($field);
                $src = $option->title;
            } else {
                $value = $sitedefaultimage;
                $src = "site-settings";
            }

            $value = $value->httpUrl;
            
            bd("og:image inherited from: {$src}\n{$value}");

            $event->return = $value;        
    }
});

I corrected  $value = $value->url; to  $value = $value->httpUrl; 

Edited December 10, 2019 by sz-ligatur
one should use absolute urls for og:image, changed @code

[VeiJari]

@Wanze Thank you for this awesome module!

We noticed a small bug on 1.0.0 version, we can't use scandic letters (Ä, Ö, Å).

This works on version 0.9.0.

 

This has something to do with UTF-8 encoding not enabled on 1.0.0?

[Wanze]

Hi @VeiJari

Thanks! ?

It seems that my "fix" to support german umlauts in meta tags breaks letters in other languages. ?
Can you change the code according to this issue? https://github.com/wanze/SeoMaestro/issues/15

I'll release a version 1.0.1 which fixes this as soon as possible.

Cheers

[VeiJari]

On 11/27/2019 at 8:28 AM, Wanze said:

Hi @VeiJari

Thanks! ?

It seems that my "fix" to support german umlauts in meta tags breaks letters in other languages. ?
Can you change the code according to this issue? https://github.com/wanze/SeoMaestro/issues/15

I'll release a version 1.0.1 which fixes this as soon as possible.

Cheers

Hi @Wanze

This temporary fix works, thank you!

[dragan]

@Wanze

Just a quick heads-up re: encoding issue: the fix by @tiefenb works in my setup (using the default PW multilang profile).

(Previously, for every instance of "inherit default value" used, Umlaute were b0rked, while manually overwritten values were displaying OK.)