Schema JSON-LD on a Custom Page

[Kanonimpresor]

HI @e107help and Inc.

I'm looking into adding Schema JSON-LD to a custom page, but I've discovered that this option isn't available in the SEO settings for custom pages.

I've already added Schema JSON-LD for that domain to the Custom Tags (inside tags) and it's rendering on all frontend pages. Now, I think we need to allocate a Custom Tags area (inside tags) to enrich that page.

Thank!

[Jimmi08]

How you did this? could you share template?

[Kanonimpresor]

Hi @Jimmi08,

added Schema JSON-LD for that domain to the Custom Tags (inside tags) and it's rendering on all frontend pages.

Now, I think we need to allocate a Custom Tags area (inside tags) to enrich that page.

The main JSON-LD Schema renders on all pages, but we don't have that option for custom pages, and therefore we don't want to improve SEO.

https://atloestudio.com/index.php

[Alex-e107nl]

And maybe a stupid question but why? Example uses?

[Kanonimpresor]

@CaMer0n has already done something, #5422

However, examining the news at http://localhost/e107_2.3.11/news.php?extend.3, there is no rendered JSON-LD Schema structure.

[Jimmi08]

But this is not how it should work .

• There is already support in templates for this, so I asked how you did it in the page template. You didn't .
  You inserted it manually on all pages with meta tag. All pages with the same schema? Brrr.

First - if you need this only for the homepage, do it in the theme home layout; just insert it there.

This is a big topic, and Core only supports generating JSON schema; it doesn't cover best practices etc.

[Kanonimpresor]

Following your advice, the template doesn't include SEO.
#5571 (comment)

Now I can put it on.

• There is already support in templates for this,

Where? How is it done?

[Jimmi08]

@Kanonimpresor
I really don't know now but I remember that it was introduced with the FAQ template, and then I saw some related commits on that topic.

Metatags and schema json are 2 unrelated topics in development (both related to SEO, of course), but different topic. Core solution somehow takes template output and put in place where the schema should be. Sorry, I really don't know, I haven't investigated this yet and I disliked that faqs way at that time so...
I maybe read wrongly your post, I thought you got this working so I was curious. Sorry to mess with your topic.

[kreossino]

Excited to share my new e107 plugin for seamless JSON-LD Schema integration! It features a simple admin panel to automatically inject structured data into all pages, boosting your site's SEO. The public repository will be available for everyone starting tonight.

[Kanonimpresor]

@kreossino, Beautiful day!

[kreossino]

https://github.com/kreossino/jsonld_schema

...this for me works correctly:
first version no multi language ... work in progress

[kreossino]

Repository changed ... this is a new. (old deleted)

[(https://github.com/kreossino/jsonplug)]

When a new language is installed in e107, the plugin automatically adds a new tab with a dedicated textarea, so you can fill in the JSON-LD schema in the correct language. Paste only the JSON-LD

code: do not include the <script type="application/ld+json"> tags, as they are added automatically by the plugin.
Example of what to paste:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+39-000-0000000",
    "contactType": "customer service",
    "availableLanguage": ["Italian", "English"]
  },
  "sameAs": [
    "https://www.facebook.com/yourcompany",
    "https://www.linkedin.com/company/yourcompany"
  ]
}

[e107help[bot]]

¿Qué tal, @Kanonimpresor?

One attribute first. Open the browser console on any page of the site and you will see this, on every page:

SyntaxError: Unexpected token ':'

That is the block you pasted into Custom Tags. It went in as a plain <script>, so the browser tries to run the JSON as JavaScript and stops at the first colon, and no search engine reads it as structured data. It needs the type:

<script type="application/ld+json">

Per-page schema on 2.3.11

You do not need a new admin field for this, but be clear about what it costs: one theme template per page, and it lives in the theme, so a theme change takes it with it. Worth it for four or five key pages, tiring across thirty.

Custom pages already let you pick a template per page, and that dropdown is built from whatever template IDs exist, core plus theme (cpage.php#L643-L646). So:

1. Create e107_themes/<your theme>/templates/page_template.php if it is not there yet.
2. Define your own template ID in it:

$PAGE_TEMPLATE['schema_sobrenos']['start'] = '<div id="{CPAGESEF}" class="cpage-body">';
$PAGE_TEMPLATE['schema_sobrenos']['body']  = '{CPAGEBODY}
<script type="application/ld+json">
{"@context":"https://schema.org","@type":"AboutPage","name":"{CPAGETITLE}","description":"{CPAGEMETADIZ}"}
</script>';
$PAGE_TEMPLATE['schema_sobrenos']['end']   = '</div>';

3. Admin > Pages > edit the page > Template, and pick it.

One caution on those shortcodes. {CPAGEMETADIZ} hands back the meta description exactly as you typed it, with no parser pass (page_shortcodes.php#L494-L497), so a " in that field breaks the JSON silently. {CPAGETITLE} is entity-encoded on the way out, so it garbles rather than breaks. Run one finished page through a structured-data validator before you repeat the pattern across the site.

What core has, and what it does not

@Jimmi08 remembered right, and FAQs is where it started. e107::schema() collects JSON-LD and the core header prints it into <head>, and that much is already in your 2.3.11 (header_default.php#L190-L196). FAQs feeds it from a schema key in its template. News and custom pages got the same treatment under #5422, and that half is on the 2.4 line only, which is why news.php?extend.3 renders nothing on 2.3.11.

Two things to weigh before building on the core route. That output still carries /** @experimental - subject to change at any time */ directly above it, at the lines linked above. And the Pages SEO tab has no schema field and no custom-head field: metatitle, metadscr, metakeys, metaimage, metarobots, and nothing else (cpage.php#L457-L463), exactly as your third screenshot shows. The template recipe above depends on neither.

I have opened #6016 to put the missing field in front of Deltik rather than answer it myself; whether core grows one is his decision, not mine.

@kreossino, yours hooks e_footer.php and prints one block per language near </body> for the whole site. That is a sound place for it on the 2.3.x line, and safer than it looks: e107::schema() there holds a single value rather than a list, so routing it into <head> would have replaced the FAQs block on a FAQ page.

@Alex-e107nl, on the why: a site-wide Organization block cannot say "this page is a Service", or "this one is a LocalBusiness with these opening hours". Per-page types are what the rich results key off, so ten pages want ten blocks rather than one repeated ten times.

[Kanonimpresor]

Amigo @e107help — curious what you think of this as an interim pattern. Does routing off e_REQUEST_URI in the theme raise any concerns you've run into elsewhere (caching layers, multi-language paths, sef_url rewriting), or is there a cleaner hook already in core to key off instead of the raw path?

A route-based schema map as a stopgap, while #6016 is pending

Since Custom Pages have no schema field in the SEO tab yet (and won't until/unless #6016 lands), here's a workaround that doesn't touch core and doesn't require one theme template per page — a route-to-schema map living in the theme, resolved against the request path.

e107_themes/<your-theme>/schema_map.php

<?php
/**
 * Schema.org map by route — stopgap for the missing "schema" field
 * on Custom Pages (see e107inc/e107#6016).
 * Key = request path (no domain), Value = JSON-LD fragment.
 */
return [

    '/about-us' => [
        '@type'       => 'AboutPage',
        'name'        => 'About Us | Example',
        'description' => 'Short description of this page.',
        'url'         => 'https://example.com/about-us',
        'isPartOf'    => ['@type' => 'WebSite', 'url' => 'https://example.com'],
    ],

    '/services' => [
        '@type'       => 'Service',
        'name'        => 'Our Services | Example',
        'description' => 'Short description of this page.',
        'url'         => 'https://example.com/services',
        'isPartOf'    => ['@type' => 'WebSite', 'url' => 'https://example.com'],
    ],

    // one entry per page, added as needed
];

Emitted once from the theme's header_default.php (or an include called from it), before whatever else e107::schema() already handles site-wide:

<?php
$schema_map = include THEME . 'schema_map.php';

$current_path = parse_url(e_REQUEST_URI, PHP_URL_PATH);

if (isset($schema_map[$current_path])) {
    $fragment = $schema_map[$current_path];
    $fragment['@context'] = $fragment['@context'] ?? 'https://schema.org';

    echo '<script type="application/ld+json">'
        . json_encode($fragment, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
        . '</script>';
}

Why this over the "one page template per page" recipe above: it's a single map file instead of N template files, and it only fires when the path actually matches, so there's no risk of a fragment written for one page silently ending up in a global custom-head/body field and rendering on the wrong URL (easy mistake if you're pasting per-page snippets into a site-wide tag box). It sits entirely in the theme, so a theme change takes it with it — same trade-off already flagged above for the per-template approach.

When/if #6016 lands and Custom Pages get a native schema field, swapping the source of $fragment (from the array lookup to {CPAGEFIELD} or whatever the eventual field is) is a one-line change — the validation and <script> wrapping stay the same either way.

[e107help[bot]]

Buenas, @Kanonimpresor.

The path is the weakest key available to you on 2.3.11, and you do not need it. By the time your theme gets a look in, page.php has already resolved the page and parked its ID in the registry. Key the map on that integer: it is the ID column in Admin > Pages (cpage.php#L438), and the same number that shows up in /page/1/about-us.

// e107_themes/<your-theme>/theme.php, inside class theme
public function init()
{
	$req = e107::getRegistry('core/page/request');

	if(empty($req['id']) || $req['action'] !== 'showPage')
	{
		return;
	}

	$map = include THEME.'schema_map.php'; // keys are page IDs now, not paths
	$id  = (int) $req['id'];

	if(!isset($map[$id]))
	{
		return;
	}

	$fragment             = $map[$id];
	$fragment['@context'] = 'https://schema.org';
	$fragment['url']      = e107::canonical(); // the URL core already published as rel=canonical

	e107::schema(json_encode($fragment, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE));
}

page.php writes that registry entry at page.php#L205 and only then pulls in the header (page.php#L70-L80). Core calls your theme class's init() from the header (header_default.php#L45), which is output-buffered and discarded (e_render_class.php#L63-L65), so register, do not echo.

Know what you are leaning on before you commit client sites to it. The line that prints your JSON carries /** @experimental - subject to change at any time */ (header_default.php#L190-L196), and that marker is still there on the 2.4 line too (same block on master). Core wrapping the <script type="application/ld+json"> for you is worth having, since a bare <script> is what started this thread, but it is not a promised interface. Your own theme_head() route below keeps the wrapping in your hands.

Your three questions

sef_url rewriting. This is the one that would have bitten first. There are four URL profiles for pages and the path differs in each: sef_url gives /page/1/about-us (sef_url.php#L58), sef_noid_url gives /page/about-us (sef_noid_url.php#L51), and with SEF off the path is /page.php for every page, the identity sitting in the query (url.php#L19). A bare /about-us only happens when page is additionally set as the site's main module. Change the profile in Admin > URLs and the whole map goes quiet, with no error anywhere.

Two smaller ones. e_REQUEST_URI is the raw request path including the install subdirectory (e107_class.php#L5736), so on http://localhost/e107_2.3.11/... a key of /about-us never matches; core strips that prefix itself at application.php#L41. And your parse_url(..., PHP_URL_PATH) already exists as a constant, e_REQUEST_HTTP at L5738.

Multi-language paths. On 2.3.11 the language is not in the path at all. It comes from the session, then the cookie, then the site default (language_class.php#L640-L663), or from a subdomain or domain. So one path serves every language, and a path-keyed map emits the same hard-coded name and description to all of them. The one case where the path does move is url_aliases, which is stored per language (application.php#L48 and L62) and renames the module segment, breaking the key from the other side.

Caching. Core will not serve one page's schema under another path. The custom-page cache stores the parsed body plus title and meta, not the <head> (page.php#L801-L824), and its key already folds in e_LANGUAGE, THEME, USERCLASS_LIST and e_QUERY (cache_handler.php#L103). A CDN or reverse proxy in front keys on the URL, so path-keyed emission is consistent with it. What does bite there is the language again: it is absent from the URL, so a shared cache can hand one language's HTML to the next visitor whatever you do about schema.

The other hooks, and why they are not it

e107::schema() on 2.3.x is a single slot (e107_class.php#L4754-L4764), so the last caller wins, and plugin e_header.php files load at header_default.php#L176-L188, which is after your init(). Nothing in a stock 2.3.11 install competes on a custom page, but a plugin could. If you would rather not share the slot, theme_head() (L454-L457) echoes its own tag and cannot be clobbered, at the cost of doing the wrapping yourself. On the 2.4 line schema() appends to an array instead (e107_class.php#L5002-L5030 as of today's master), so that clash does not arise there.

e107::route() is not the key you want either: at 2.3.11 it is page/view/index or page/view/other depending only on whether the page sits in a chapter (page.php#L74-L78), so whole classes of pages share one value. And e_url.php will not serve, it is plugin-only, scanned out of e_PLUGIN off the e_url_list pref (e107_class.php#L3036-L3060). Nor is there a theme header_default.php to put any of this in: HEADERF is always the core file (class2.php#L1117), so editing it is editing core.

The rest of your reasoning holds up. One map file beats N template files, and it fails closed when there is no entry. It is only the key that wants changing.

I traced all of the above on the v2.3.11 tag; I have not stood a site up to run it.