No field type?

[mofman]

In the previous version of seomatic you were able to create a field called SEO and drop it into a new tab on all sections - this made the whole job very simple? Has this concept been done away with? Must users now great all the fields manually now? How about creating some Migrations even for these and grouping them?

[khalwat]

So as noted in the beta notes:

https://github.com/nystudio107/craft-seomatic#seomatic-beta-notes

• Field - there is no SEOmatic Field anymore; it's not necessary given the new architecture. Depending on demand, it may be brought back.

The reason there is no Field is that modern SEO should pull from content that appears on the page. You can edit on a per-section basis what fields are pulled from, or for Singles or such, you can enter the custom text you want in there.

Still, I could probably be convinced to bring the Field back. I'll see the issue open to see how others feel about.

[mofman]

Sorry I missed this in the release notes

you can enter the custom text you want in there

I understand the ratioanle - basically if SEOMatic is set up properly from the start it will work automatically, however I still think we're going to have to give the users some flexibility so at a minimum we'll have to create a 'SEO Title' & 'SEO Description' Fields when creating new sites and map these.

[riasvdv]

A built in fieldtype has several disadvantages:

• You can't make fields individually required or not
• You can't disable or hide fields easily
• You can't change the translations or descriptions of the fields as you please

Creating your own fields (SEO specific or not) and having SEOmatic pull from them, is a lot more flexible (and robust, if you ever want to use a different SEO plugin) than having a built in fieldtype.

[khalwat]

Hrm. Well, I guess my concern is that people may then stuff the SEO Title & SEO Description with content that isn't represented on the actual page... which is bad from an SEO POV.

So what you're viewing as flexibility, I'm viewing as concerning, if that makes sense?

I realize that SEO firms love to spend the time putting custom SEO Titles and SEO Descriptions in, and perhaps I should just let them via a Field. But I feel like we're not doing the right thing if we do it that way.

Modern SEO works best if it actually reflects what is on the page, visible to the user

But like I said, I'm open to the idea, and the architecture definitely will support a Field that if present, will override the Content settings.

[timkelty]

I'm torn here - personally I like the idea of no field type - in 2.x it has been the source of most of our trouble with Seomatic. Basically you end up with tons of serialized data that in actuality might have like 2 bits of actual data in it, which becomes very hard to migrate, parse, or deal with in general.

However, changing a meta value for a single entry in a "general use" section, (e.g. a "Pages" structure) becomes a little more work. Mostly in the fact that you would need to create fields for everything you wanted to override.

Proposal

In the admin of Seomatic somewhere, include a button for "create Seomatic fields", which would create regular Craft text/asset fields an "SEO" field group with a field for everything you can set with Seomatic (seomaticTitle, seomaticKeywords, etc.).

That way people will have a jump start on a full set of fields, and they can drag all of them , or just select ones, into their fieldsets.

[khalwat]

One thing to keep in mind... you can already do whatever overrides you'd like to do:

https://github.com/nystudio107/craft-seomatic#content-seo-admincp-fields

So for the Content SEO settings for a Section, you could do something like this for the SEO Description:

{entry.seoDescription ?? seomatic.helper.extractTextFromField(entry.body) ?? "Some default text"}

So that if they fill something in for the seoDescription field, it uses that. If it's empty, it extracts a summary from the "body" field (which can be a Rich Text field, or a set of Matrix blocks or whatever).

[khalwat]

btw, I don't want it to sound like I'm completely opposed to adding a Field -- it's something I've been mulling over for some time. So the more feedback I get on what people/clients want, the better.

[khalwat]

So what I'm mulling over now is an optional Field, which would be everything that you see on the Content SEO settings (General, Twitter, Facebook, Sitemap):

...but in the Field settings, you can control what actually is shown to the user. So if you just want the SEO Title & SEO Description, that's fine, that's all you'll see.

[ryanmasuga]

Based on some comments I sent to Andrew in Slack:

I need a way to allow clients to at least override the description on entries, and ideally in a way that is consistent from site to site (for us as devs...it would be weird having different SEO Description override fields on different sites, even if they differed in something small like description content or position on a tab).

To me, an automated description is cool, but I view SEO descriptions as loaded human-readable tl;dr's for a page. Yes, that same content can often be found on the page, potentially scattered around (an h2 here, a paragraph there). But for a social share, for example, sometimes you really want a custom, loaded, well-written, tl;dr sentence. That may not always be able to be automated.

That’s my argument for client overrides via the CP. And if we can get that with a way to avoid making too many fields manually, or a way to keep it consistent from site to site, that would be great.

An optional field where we elect what to show sounds interesting. I would point out that we may want to show different fields per section, though. In most cases, we'd probably show title and description. On some sections, we may not enable the field at all, because the defaults would be perfect. On some sections, like on a "Press Releases" section, we may want to include the "robots" field as an override, for example. We've had client sites where a negative Press Release had to be posted on the site for legal reasons, but they wanted robots set to noindex, nofollow on that particular entry. Another example might be a section where they would like the option to override the share image.

However, if it couldn't have elected fields per section, I'd take the optional field as an all or nothing option, and just show every field that we would need to override across all sections.

[mofman]

Tend to agree with @ryanmasuga here, consistency is definitely something which needs to be considered with how things are laid out just for mussle memory etc. I guess you could disable field if you wanted SEOMatic to take care of them?

[juresrpcic]

While building a custom SEO override fieldtype where you can select what to show on each section sounds nice in theory, I think it's just adding extra stuff where a normal Craft field does the job just fine (just adding a new "SEO" tab and two regular fields that are set to override default SEO fields).

However, if this override is optional, we'd still need the default option to win when clients don't add a override. I think we're one level short of that currently?

Example:

• I want the section Blog to pull from Blog description field by default for SEO description
• I also want to add a custom SEO description override (Craft text field) in a tab on this section in case someone wants to override the default

... is that already doable in some way from the SEOmatic CP already? Or would we need a second-level override (ie. pull from this default field except if there's something in the override field). I would like to stay in CP for this (not using twig in templates or config files) - so it keeps working with caching.

[khalwat]

@juresrpcic you can already do that, unless I'm misunderstanding you?

Check out my comment earlier in the thread:

#14 (comment)

Remember, you can put Twig into any of the fields in those settings:

https://github.com/nystudio107/craft-seomatic#content-seo-admincp-fields

So you'd do something like:

[ryanmasuga]

@juresrpcic My thing is, I don't want the override fields to be "normal" Craft fields. I don't want to have to make the field, and worry about trying to make it consistently (consistent title, description, text count, tab, position, etc) from site to site. Don't make me (or my clients) think. If I've installed SEOmatic, and it does as much as it does, I want all the site's SEO handled by it - including override fields (except for those less common cases where we override on the template).

My suggestion means bringing back the SEOmatic field, which you could add a tab for on a section, but it would only show the fields you've elected to let a user override for that section. So, no more having to view a mile of twitter/FB related fields if they're never going to override those.

[khalwat]

@ryanmasuga I'm leaning in that direction. I'll bring back the field, and people who want to use it can use it.

People who don't want to use it can blissfully ignore that it exists.

Flexibility is a key point in Craft CMS, and I'll try to follow that with how SEOmatic works as well.

[timkelty]

@ryanmasuga I'm leaning in that direction. I'll bring back the field, and people who want to use it can use it.

I'm waffling now and agreeing - best case is field is optional, as well as having which sub-fields display be configurable.

[ryanmasuga]

@timkelty To me, that sounds ideal, but if it's a matter of getting an optional "all-or-nothing" non-configurable per section field back, I'll take it. Just optionally add it to any section that needs more granular client control, just like you'd add the field in Craft 2.

[juresrpcic]

Yeah, that sounds ideal. I'm happy to use Twig in the fields to get more advanced uses - thanks for that example, I wasn't aware I can do it in the CP as well.

@ryanmasuga I see what you're saying and how having many custom Craft override fields could be hard to maintain - I was considering a few Matrix fields (1 block type, max 1 used) to make it easier to edit and provide more of a "grouped field" for the client - which is possible as you can pull info from that field using Twig. But of course having a custom fieldtype built in is even easier.

Thanks for all the flexibility @khalwat !

[lindseydiloreto]

I'm weighing in on this, despite the fact that I don't have strong feelings one way or the other...

I personally like the idea of "no field needed". I'm not sure how you work that magic, but perhaps I trust you too much @khalwat. 😉

If there is a field, it sounds like it would just be a GUI version of your Twig overrides, in the sense that omitting the field would give the "everything works" effect you say it already has. Is it really that simple?

[ryanmasuga]

A field is not exactly "just a GUI version of ... Twig overrides" - a client has the ability to edit the content of a field in the CP, which is the point of an override field...but the client has no control on a template.

I think I'm agreeing with you, though - no field by default - but allow a dev to add a commonly structured field to a section if you need to let the client do any kind of overriding.

[khalwat]

This will be coming in the next beta (3.0.0-beta.20) FYI.

[khalwat]

So here's what we have. When you create the Field, in the Field settings, you have quite a bit of control over what gets displayed:

It'll appear like this (with everything on):

...but the defaults are a little more sane, letting the client see just a few things they might want to change (but again, up to you what gets displayed there):

[lindseydiloreto]

That looks great @khalwat! The old field was a bit overwhelming... this looks way, way better. 👍

[khalwat]

You can make it look as overwhelming or underwhelming as you want now... tailored on a per-Field basis. :)

[khalwat]

Implemented as of ace2fc7

Expect it in 3.0.0-beta.20, which will be out soon-ish.

[Gnative]

Thank you.. this is perfect..

[juresrpcic]

Great solution - not crowded and as powerful as you want it. Thanks!

[mofman]

On Mon, 2 Apr 2018 at 11:14, Jure Srpcic ***@***.***> wrote: Great solution - not crowded and as powerful as you want it. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5b2TXb1N_nKjX3S5xTqLXfXWFjKIqYks5tkfoHgaJpZM4Sqklh> .

Great work andrew!