Jump to content

Wanze

PW-Moderators
  • Content Count

    1,099
  • Joined

  • Last visited

  • Days Won

    10

Wanze last won the day on February 6

Wanze had the most liked content!

Community Reputation

1,553 Excellent

2 Followers

About Wanze

  • Rank
    Hero Member
  • Birthday 06/19/1986

Profile Information

  • Gender
    Male
  • Location
    Bern, Switzerland

Recent Profile Visitors

13,050 profile views
  1. Wanze

    SeoMaestro

    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
  2. Wanze

    SeoMaestro

    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.
  3. Wanze

    SeoMaestro

    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 ๐Ÿ™‚
  4. Wanze

    SeoMaestro

    Hi @adrian You could use the solution mentioned by @sz-ligatur 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. 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
  5. Wanze

    SeoMaestro

    @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
  6. Wanze

    SeoMaestro

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

    SeoMaestro

    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?
  8. Wanze

    SeoMaestro

    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
  9. Wanze

    SeoMaestro

    I agree. Could you open an issue on GitHub? Should be easy to integrate this in the next release. @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
  10. Hi Markus, Why do you want to parse it yourself? ๐Ÿ™‚ Twig and Smarty have built-in parsers and both offer to extend the parser with your own functions / filters / modifiers and so on. Twig even allows you to write custom expressions. Here is an example how to integrate the "__('text') function into Twig, assuming you are using the TemplateEngineFactory in combination with the TemplateEngineTwig module. $this->addHookAfter('TemplateEngineTwig::initTwig', function (HookEvent $event) { /** @var \Twig_Environment $twig */ $twig = $event->arguments('twig'); $function = new \Twig_SimpleFunction('__', function ($key) { return __($key, "/site/templates/translations/strings.php"); }); $twig->addFunction($function); }); As you can see, I'm collecting all my translatable strings in a PHP file "strings.php". But you could also extend the twig function to optionally accept the text domain. Cheers
  11. Wanze

    SeoMaestro

    @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
  12. Wanze

    SeoMaestro

    @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
  13. Wanze

    SeoMaestro

    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.
  14. Wanze

    SeoMaestro

    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
  15. Wanze

    SeoMaestro

    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
ร—
ร—
  • Create New...