Wanze

@Juergen @Peter Knight There is a render() method for any "group", but in case of the robots it will only return something if at least one option (noIndex, noFollow) is checked. Your example to access the individual data is correct, you can also use the following syntax, which looks slightly nicer: $page->seo->robots->noIndex Cheers

@Juergen What version of ProcessWire and which AdminTheme are you using?

Hi @Peter Knight, $page->seo->robots->render() should work fine, but it only outputs the tags if you have checked any of the noIndex or noFollow options. Cheers

@Peter Knight This is currently only possible with a hook, check out the following test case: https://github.com/wanze/SeoMaestro/blob/master/tests/src/SeoMaestroTest.php#L119-L129 But this would make a nice feature, either in the module config or configurable per field. Could you open a feature request on GitHub? Thanks ? Cheers

@alexmercenary This bug has been fixed with version 0.5.0, see https://github.com/wanze/SeoMaestro/blob/master/CHANGELOG.md#050---2019-02-17

That is not true: https://support.google.com/webmasters/answer/189077?hl=en @Michkael The meta tags added by SeoMaestro do not perform any redirects, there must be another issue either on server level or some code in ProcessWire performing the redirects.

Looks fine, if you inspect the source code you will see the XML markup. This is not a sitemap for users, but one you can submit to search engines, see here: https://support.google.com/webmasters/answer/183668?hl=en Here is a quick how-to, i did not find this feature in the docs: Create a new field of type "FieldsetTab", e.g. "Seo Settings" Use this field to group other fields that should be displayed in the new tab A screenshot is probably easier ?

Hi fellow Seo Maestros, The next version 0.6.0 adds the ability to customize the canonical URL of a page: The canonical URL is part of the "meta" group. You must enable the canonical URL under the "Input" settings of your SeoMaestro field, if the content editors should be allowed to change it. This release also includes a new hook to add custom items to the XML sitemap, useful if you have pages using URL segments to present additional content. Cheers

@tiefenbacher_bluetomato Here is an example script from my migration. Note that I did not use MarkupSeo, in my case I had two fields "seoTitle" and "seoDescription". I highly recommend using the migrations module to execute such logic. $pages = $this->wire('pages')->findMany("seoTitle|seoDescription!='',include=all"); foreach ($pages as $page) { if (!$page->hasField('seo')) { continue; } $page->of(false); foreach ($this->wire('languages') as $language) { $this->wire('user')->language = $language; $title = $page->seoTitle->getLanguageValue($language); $desc = $page->seoDescription->getLanguageValue($language); $page->seo->meta->title = $title ?: 'inherit'; $page->seo->meta->description = $desc ?: 'inherit'; } $page->save(); }

I agree. Let's put it in the meta group. ? There is also no need to setup default values for the canonical url, it always equals the page's url unless overridden.

@wbmnfktr Thanks for your feedback, glad you are liking the module. Regarding the custom canonical URL, see the following issue: https://github.com/wanze/SeoMaestro/issues/4 I really want to introduce this, as I am also in the need. What do you think about my thoughts in the GitHub issue, any preferences? Cheers

Hey @Tom. Thanks for the nice words and your feedback. I agree, it would be neat to have an image field for clients. Could you open a feature request on GitHub? I would like to discuss the implementation with you, or anyone interested in this. I guess there are may ways to achieve this, and I'm not sure which one's the best ?

Hi Andrea, Thanks! Out of curiosity, what is the reason to put the SeoMaestro field inside a repeater? Just can't think of any use case ? I'll look into it. Cheers

Hi @eelkenet Thanks for your feedback, glad you are liking the module! I see your point. Content editors are currently limited to edit meta data on page level. However, I doubt that the home page would be the desired place to to so: Setting default values on field level allows to leverage different data per template. You can edit the field in the context of any template and change the default meta data, you can even change what groups/fields are displayed to the editor per template. If we place this on the home page, we are mixing configuration and content + we would need to build another UI around that. I think the correct place to edit the default values would be a dedicated page in the admin (e.g. under "Setup"), with a new permission (e.g. "seomaestro-edit-config") that you could give to your content editors. I am not 100% sure what you mean by "follow the same inheritance structure as pages do". Does this mean that any page should inherit meta data of the parent page, unless overridden? I do not think that this works well for meta data, because the goal is to have unique meta data (no duplicate titles or descriptions). This data must be defined on the current page, or mapped from a field of the current page. This should work already ? Just enter {title} | {parent.title} and save the page. Cheers

A lot of the rules protect direct HTTP access to sensitive files such as config, logs, sessions, templates... most other frameworks and CMS's keep this sensitive stuff out of the web root, so HTTP based access is not possible by design. In ProcessWire, the root directory equals the web root directory, so we need to protect access to these files. On the plus side, ProcessWire can be installed on hostings that do not allow to change the web root. The drawbacks are that we need to be extra careful that nobody can access sensitive/private files.

Version 0.5.0 fixes two issues, please update: Fix wrong url in the <link rel="alternate" hreflang="x-default"> meta tag. Fix date formatting for the lastmod property in the XML sitemap. Cheers

Actually I wanted to ask you if you would like to develop the 2.x version of TemplateEngineSmarty, and if you like, maintain the project? The implementation itself is really easy, you can basically copy + past from Twig and tweak/change things for Smarty. I only use Twig these days, so I might miss some useful/important stuff for Smarty. What do you think? ?

Hi folks! I release a now major version 2.x of the TemplateEngineTwig module. This version is compatible with the newly released 2.x version of the TemplateEngineFactory (more details in this post). Note that the new version of the TemplateEngineFactory might break backwards compatibility, depending on the feature usage. Read the following guide on how to update, before you do so. So what's new in version 2.0? Updated Twig to 2.6.2 Added a setting to enable debug mode, independently from ProcessWire's debug mode. The Twig_Extension_Debug is automatically loaded if debug mode is active. Added unit tests and Travis for CI. Note that this version no longer bundles Twig. Therefore, installation is only possible with Composer. This makes sure that the 3rd party dependencies are handled correctly. If you update from 1.x to 2.x, please let me know any issues you have. If you do not update: The 1.x version of the module will stay available on the 1.x branch. For a new project, definitely pick version 2.x! Cheers

Hi folks! I just released a new major (2.x) version of the module. Important things first: This version includes backwards compatibility breaks. At the moment, only Twig and the bundled ProcessWire engine work with the 2.0 version. I will now contact maintainers that implemented other engines (Pug, Jade etc.) and ask them to release a 2.x version as well. The 1.x version of the module is still available on the 1.x branch and continues to exist. So why a version 2.x? Basically it's the same concept, but done in the right way. ? The rendering via template engine is now integrated correctly into Page::render(). You can call the render() method on any page, and the module will render it via template engine. In version 1.x, this is only true for the current page. Automatic page rendering is now optional, you can use the module to only integrate a template engine, without hooking into Page::render at all. There are settings to enable/disable the automatic page rendering for templates. Because there might be templates where Page::render should not be replaced. The module provides hooks to customize it for your needs. I wrote a bunch of unit tests and use Travis for CI. Problems like "the 404 page is not displayed if a Wire404Exception is thrown in a controller" are now tested properly. I am writing a documentation on everything, you can read it here: https://github.com/wanze/TemplateEngineFactory/blob/master/DOCUMENTATION.md One important part is how to update from 1.x to 2.x. Depending on the feature usage of the module, this might involve some manual update steps, because the public API changed. If you try to update, please let me know about any issues you are encountering, so that we can add them to the documentation. Don't worry, you do not have to update, as the 1.x version continues to exist. For a new project, definitely start with 2.x! Last but not least, modules providing template engines must be updated too, but this should be quite easy. For Twig, I decided to support installations only via Composer, and I think that this should be the way to go for the other modules. 3rd party dependencies must be manageable in a reliable way, and Composer is the right tool for this job. Cheers

LostKobrakai is right. Laravel's dependency injection container automagically resolves type-hinted objects, see: https://laravel.com/docs/5.7/container#automatic-injection

@csaeum Are you sure that the name of your Seo Maestro field is "seo"? Did you create the field? Looks like the $page is not aware of it. Cheers

Version 0.4.0 renders some common meta tags not managed by the fieldtype, and fixes a couple of issues reported. Thanks! See https://github.com/wanze/SeoMaestro/releases/tag/v0.4.0 for more information. Cheers

Thanks @B3ta I think that the decision where the Seo Maestro field is rendered should be left to the user. And it should be done in the same way it works for all fields: By editing the template and placing the field. Display it in a new tab? Create an InputfieldFieldsetOpen and wrap the field. But maybe the content editor only needs to see meta title and description - then it's not worth to create a new tab. I understand that it requires some manual work to add the field to all templates, but I don't think it is the responsibility of the module to do this. There are other solutions like the Migrations module, which can do this task in a few milliseconds. For the project I built this module, it took me 10 minutes to write a migration that creates and configures the field, adds it to all templates, tweaks the settings per template and also wraps it in a tab. No need to do this by hand if I deploy to production. Cheers

It's possible! From the Sanitizer class description: Cheers:)

Version 0.3.0 should fix problems on single language installations. ? I will update Travis CI to run the test suite on two installation profiles (single and multi language). This is possible, just wrap the Seo Maestro field in an InputFieldsetOpen.