Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Wanze last won the day on February 6

Wanze had the most liked content!

Community Reputation

1,544 Excellent


About Wanze

  • Rank
    Hero Member
  • Birthday 06/19/1986

Profile Information

  • Gender
  • Location
    Bern, Switzerland

Recent Profile Visitors

12,931 profile views
  1. Wanze


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


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


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


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


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


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


    Hi guys, I just released version 0.9.0 of the module which includes some fixes and new additions, you can find all the details in the changelog. What's new? The module offers a new section "Webmaster Tools" when editing a field, allowing you to set verification codes for Google and Bing. If set, these codes are rendered as additional meta tags. I had to refactor the UI in order to separate the webmaster tools from editing the default values. My solution was to separate them via fieldsets: Cheers
  9. Wanze


    Hi @antpre Your PHP version is most likely below 7.0, try to update. Some more information about this error can be found here: Cheers
  10. Wanze


    Glad it works, thanks for the feedback! This fix will be integrated in the next release, so you'll be able to update safely. Cheers
  11. Wanze


    Hi @sz-ligatur Looks like you've found a bug! The relevant code is here: https://github.com/wanze/SeoMaestro/blob/master/src/MetaSeoData.php#L30-L35 It looks like these lines do not grab the field's value in the current language. Can you try to change the code like this: // Old if ($field->get('meta_title_format')) { $value = str_replace('{meta_title}', $value, $field->get('meta_title_format')); } // New $metaTitleFormat = $field->get('meta_title_format' . $this->getCurrentLanguageId()) ?: $field->get('meta_title_format'); if ($metaTitleFormat) { $value = str_replace('{meta_title}', $value, $metaTitleFormat); } Not tested and written in the browser, but maybe it works ๐Ÿ™‚ Cheers
  12. Hi @regesh Wrote you back on GitHub, hope it helps: https://github.com/wanze/TemplateEngineTwig/issues/22 Cheers
  13. Wanze


    Thanks @elabx The module allows to fallback to fields using placeholders. For example, if your page has a field lead_text, you can set the default value of the meta description to {lead_text}. If the content editor omits the meta description of a page, it will fallback to the lead text. It is not possible to fallback to multiple fields though. Does this answer your question? Cheers
  14. Wanze


    Hi @teppo Thanks for your valuable feedback! What do you think about calling the label "Inherit default value"? For the explanation, we could use an InputfieldMarkup prior to any meta data fields (similar to the one when editing the default values on field-level). It has been mentioned before that it should be possible for content editors to edit default values without having permission to edit fields or templates. I think the module will (should) include another Process module, which could offer this configuration GUI, along with other interesting things such as SEO reports ๐Ÿ˜‰ The sitemap does not have to be in the site root necessarily, you could also enter a path to a writeable folder. But you're right, I actually never thought of this problem and also do not check it ๐Ÿ˜… At least this should be mentioned in a description or note. I am aware of the 404 hook, but I do not like it very much, it feels "wrong". Other hooks listening to the 404's might get triggered as well, but then it's no longer a 404 after returning the sitemap. Let me think about this ๐Ÿ˜„ Cheers
  15. Wanze


    SeoMaestro (including myself) knows nothing about TemplateLatteReplace, so I cannot influence settings of this module. I am not sure why the LatteReplace would try to render the structured data template, I assume it's because SeoMaestro internally uses a ProcessWire TemplateFile to render the markup: https://github.com/wanze/SeoMaestro/blob/master/src/StructuredData/BreadcrumbStructuredData.php#L52-L55 There is nothing I can do from Seo Maestro's side about this, and I assume you will have problems with other modules as well that are using ProcessWire's TemplateFile for rendering. My TemplateEngineFactory module providing template engines like Twig, Smarty, Pug etc. does not suffer from this problem, because it hooks after Pager::render rather than TemplateFile::render. Cheers
  • Create New...