• Resolved vanetreg

    (@vanetreg)


    Hi,

    do you plan to modify WPSSO Free or Pro or create a Pro addon to add markups to Gutenberg content blocks?
    All that we can add now to WP posts, pages, CPTs, Woocommerce products, etc.
    If so, is there any target date?

    Thanks!

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author JS Morisset

    (@jsmoriss)

    The Document SSO metabox allows you to define meta tag and Schema information for the document as a whole. The WPSSO JSON Pro v1.31.0-dev.2 add-on currently in development also detects JSON-LD markup in the content and adds it to the main Schema markup under the “hasPart” property. See here for more info: https://wpsso.com/extend/plugins/wpsso-schema-json-ld/?section=changelog

    For example – Yoast SEO has just released an update with support for FAQ and How-To blocks. WPSSO JSON Pro v1.31.0-dev.2 will include the markup from those blocks into the main webpage Schema markup.

    You can expect that a variety of Schema-type blocks to available from WPSSO and other plugin developers in the future. The WPSSO JSON Pro add-on will include markup from future WPSSO blocks, along with other 3rd party blocks.

    The “schema” shortcode can also be very useful, if you want to have a finer control over specific properties. See here for more info: https://wpsso.com/docs/plugins/wpsso-schema-json-ld/notes/schema-shortcode/

    js.

    I meant something like can be seen on your screenshot:
    https://surniaulula.github.io/wpsso-schema-json-ld/assets/screenshot-03.jpg?20180911
    so we could edit such WPSSO metadata for Gutenberg Content Blocks (GCB) like it is used for post or CPT (custom post type) of Recipe.
    That WPSSO metabox bordered in green on screenshot could be used also for GCBs, if I’m not wrong.
    The Yoast way (adding schemas one-by-one) is not preferred, that’s why I consider to buy your:
    WPSSO Core Pro
    and
    WPSSO Schema JSON-LD Markup Pro

    • This reply was modified 10 months, 1 week ago by  vanetreg.
    Plugin Author JS Morisset

    (@jsmoriss)

    Those fields are provided when the Schema type for the document is “Recipe” (the Schema type can be set manually, or automatically based on the CPT or supported recipe plugins).

    The Document SSO metabox (shown in the screenshot) is document / webpage level information, and NOT block level information.

    If / when blocks are added that create Schema markup, they will be added to the main Schema markup (requires WPSSO JSON Pro v1.31.0-dev.2).

    So, you can use Schema WebPage (for example) as the main markup, with Schema Recipe blocks, or you can use Schema Recipe as the main markup with recipe information (from the Document SSO or a supported recipe plugin) in the main markup. You probably wouldn’t have a Recipe within a Recipe though – although you could do that if you wanted to. 🙂

    js.

    Recipe was just an example, after selecting that screenshot as example for you.
    I understand that WPSSO and its addons are working on a higher entity level, my original question was whether you plan to extend its function to lower levels like GCB content blocks?
    I think if one takes time to set up his content by schema.org, might want to do it as good and detailed as possible.
    So one might want to set it up on page/post/CPT/custom taxonomy etc. level (document level), but also on lower, GCB level, if possible.
    There might be a content block named eg. WPSSO Content Block, which would be nested into a standard GCB and that WPSSO CB would use the same WPSSO metabox editor to set up its meta.
    But pls. consider it only as a feature suggestion with 1 vote 🙂

    • This reply was modified 10 months, 1 week ago by  vanetreg.
    Plugin Author JS Morisset

    (@jsmoriss)

    Yes, that is what I explained above. The Document SSO metabox allows you to control the main markup, while the new WPSSO JSON Pro add-on will pickup the individual parts within the content, like the new Yoast SEO “How-To” and “FAQ” blocks create. WPSSO could offer Schema themed blocks, like Recipe, Product, Review, How-To, FAQ, etc., but I’m guessing a lot of these kinds of blocks will be provided by other plugins – we’ll have to see. 😉

    The value of WPSSO is in gathering (and customizing) information about the current webpage and providing that information under a single Schema type. 🙂 I could potentially see an add-on to provide “Social and Search Optimization” blocks, like Recipe, for example – we’ll have to see. 🙂 Did you have a specific Schema type block you’d like to see being added?

    js.

    I’d use Organization, Brand, Rating, Review, AggregateRating in Gutenberg Content Blocks in first step of my project, LocalBusiness, Product, Service, CreativeWork (and some of its children) later.

    • This reply was modified 10 months, 1 week ago by  vanetreg.
    Plugin Author JS Morisset

    (@jsmoriss)

    Hm. Ok… Let’s look a the practical application of this… Say you had a “Brand” block in Gutenberg to show Brand information in your content. What kind of Brand information would you like to display in the content? And how would that information relate to the webpage Schema type? What Schema type would you image the webpage would be (ie. the Schema Type selected in the Document SSO metabox)?

    js.

    vanetreg

    (@vanetreg)

    A website or a webpage usually contains mixed, multiple type (schema) of contents, so it’s harder to clearly identify the correct schema (like Brand) on website/webpage level, than in Gutenberg Content Block’s level.
    So that’s why I’d prefer to add schemas on GCB level.
    I think I would use schemas WebSite and WebPage correspondingly, using some properties like: mainEntity, mainEntityOfPage, where the value of this property would be the Brand (NFL) or Organization (Google Inc.)
    I’d use schemas like Rating, Review, AggregateRating and features like reviews, reviewAspect, reviewRating. Every schema entity is in separate GCB on a webpage.
    I’d define separate custom post types (CPT) for every each top level schemas like Organization, Brand in first step, (for LocalBusiness, Event, Product, Service later), for listing, sorting, filtering purposes.

    Plugin Author JS Morisset

    (@jsmoriss)

    Thanks, but I think you’re missing the point here – blocks are parts of the overall content, yes, and they have their own Schema type, and are related to the overall content type in some way. For example, when using WooCommerce, a product page is a Product, and the product Brand is added to the “brand” property. In the case of WooCommerce, extensive markup is created from the available product data.

    You didn’t really answer my question about an example Brand block. Let’s say you have a Brand block and enter information about that brand to show it in the content area. What Schema type would you use for the webpage? How would that brand relate to the webpage Schema type? https://schema.org/WebPage is a bit generic – most people look to use a Google support Rich Card type – but let’s say we use WebPage in this example, as you suggested. How would the Brand block relate to the Schema WebPage type?

    js.

    Plugin Author JS Morisset

    (@jsmoriss)

    You mentioned aggregate ratings – since these are created from customer / reader ratings and reviews, how would that work as a block? What would the block display?

    As for the main entity – I don’t see a block being a main entity – it’s a part of the content, and that content is the main entity. The Document SSO metabox, for example, documents the main entity.

    js.

    vanetreg

    (@vanetreg)

    If I must be more specific regarding the Document SSO metabox, I’d use Brand schema for the entire webpage, despite that the page gonna display also the page header, footer, menu, additional navigation elements like filtering, related (non-Brand) contents and ads, so it is surely not 100% Brand content.
    I’d define separated custom post types (CPT) for every each schema.org entity, like Organization, Brand or Review.
    I use Toolset pack’s Types component for creating and managing CPTs, custom taxonomies, custom fields (CF)… Toolset uses shortcodes to display them.
    So my idea is to insert Toolset shortcodes (of CPTs and CFs) into Gutenberg Content Blocks (GCB) later marked up by WPSSO.
    Basically – I think – that’s good if – similarly to this
    screenshot:
    I’d be able to markup my Toolset CPTs as schema.org entities and markup other CPTs and CFs as schema properties.
    And with Toolset Types and Views I could be able to create filterable lists of these CPTs.
    I hope it clarified it a bit more 🙂

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘WPSSO support of Gutenberg content blocks’ is closed to new replies.