Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to disable specific fields/manually change fields #13

Open
tobimori opened this issue Mar 2, 2021 · 6 comments
Open

Option to disable specific fields/manually change fields #13

tobimori opened this issue Mar 2, 2021 · 6 comments

Comments

@tobimori
Copy link

tobimori commented Mar 2, 2021

In order for MetaKnight to be used in a more versatile environment, options to disable specific fields or change them manually would be a cool addition.

@jonathanmuth
Copy link
Contributor

Interesting idea. Can you give me an example of the use cases you were thinking of? Which fields would you like to disable and which fields would you like to add?

You could already use a custom blueprint based on the preconfigured SEO-tab as a starting point for further customization.

@tobimori
Copy link
Author

When I first opened this issue, I just thought of a simplification of the whole settings, maybe with the possibility of manually changing texts or descriptions with ease.

Although when I think about it now, that could also be used to aggregate meta data from already existing fields, like a product description or an excerpt of an article, which are already used elsewhere.

@grommas
Copy link
Contributor

grommas commented Mar 19, 2021

I started using your plugin in current projects and like the approach. Thanks for your work! It’s easy to translate fields or modify further after copying and editing the blueprints, but e.g. the way the title of a page is build (having dashes) limits the developer. It would be nice to have a config entry to keep it flexible or to simply turn it off like Tobias suggests. Right now I modify your plugin to customize titles, but that’s probably not future proof.

@jonathanmuth
Copy link
Contributor

When it comes to titles we could easily add the option to define the separator between page title and site title via a config option. The default would be - and could be replaced with any characters you choose. I'll make sure that goes into the next release.

When it comes to managing other fields, I think could we could offer the option to disable certain lines of the meta_information snippet via config options – but for this to be really useful the configuration would have to be applied on a per page or per template basis. So that for example on a product page we can pull in the product description as meta description while on other pages the description fields supplied by the plugin is still functional. 🤔

I am not sure how a feature like that would be best implemented. I'll have a look into it and will report back here.

@grommas
Copy link
Contributor

grommas commented Mar 22, 2021

Sounds good! Not sure if it’s caused by markdown, but the option may include the whitespaces as well. So we can have something like Site: Title.

@grommas
Copy link
Contributor

grommas commented Apr 25, 2021

I’m currently using your plugin for a page with a slightly more complex virtual setup (similar to the gallery example from kirby). In my case it’s good to keep the title from the parent page and add the index as an extended meta information in brackets. After explaining that, I want to add a short note to this topic: it would still be great to turn off features, so that we don’t have to modify the plugin. Thats likely not future proof, when it comes to updates. With that in mind we can easily add our own custom logic without overblowing the plugin for edge cases.

Maybe it’s also worth putting thumbnail configurations for the twitter and OG image in a more configurable but predefined context, but that could be handled with turning it off and writing an own logic as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants