SEO improvement: providing control over title and description of WordLift Archive pages

[cyberandy]

WordLift provides two entry points for organising entity pages and articles:

1. /wl_entity_type/thing provides a list of entities type:thing. This works for any supported entity type (i.e. /wl_entity_type/event displays all entities type:event) .

Here is how the page looks like on a normal blog. The description is a generic description of the chosen entity type.

2. /wl_topic/food provides a list of article belonging to the same topic (food in this case). Topics are derived from Wikipedia's top-hierarchy topics and are themselves entities in WordLift.

Here is how the page looks like in this case on a normal blog.

To provide SEO value to these pages we shall allow the user to:

• personalise the title of the page (in both cases, right now, the title is "Archive")
• personalise the description of the page (this can be already done for topics by updating the description of the entity but it cannot be done for entity types)

[cyberandy]

This issue has been pointed out also by another user see here: http://www.sergiostraface.it/wl_entity_type/creative-work/

I changed the priority to high.

[markkap]

The main question here is where to place the UI.

Right now (3.10) when the entity type taxonomy is created, it has the following capabilities and settings

		'manage_terms' => NULL,
		'edit_terms'   => NULL,
		'delete_terms' => NULL,
		'assign_terms' => 'edit_posts'
	);

	$args = array(
		'labels'            => $labels,
		'capabilities'      => $capabilities,
		'hierarchical'      => TRUE,
		'show_admin_column' => TRUE
	);

Which amounts to "no one can manage the terms" which leads to the terms not being displayed anywhere in the admin which is why you need to explicitly have 'show_admin_column' => TRUE

If we can enable the admin UI to manage the entity type terms, we can place the SEO related setting field at the admin pages for that term. The question here is who will have the permission to handle the SEO, and do we want to expose the ability to change the names/slugs/descriptions of the terms. We can easily prevent terms from being deleted but not much more than that.

The other option is to place a settings page under the vocabulary menu (or wordlift), and in that page have the setting per entity type. This will not scale well, but for 7 entity types it might be good enough.

I think that there is less risk in the second option, unless the long term intention is to let users have more control (slugs for example) over the entity types

[cyberandy]

Currently when, in the article metadata a topic is chosen for a given article, we create the entity for that topic (i.e. /wl_topic/sport/). I would do the same as long as there is at least one entity for that type. We could provide the sameAs (as we already do for topics) as links to DBpedia (i.e. http://dbpedia.org/ontology/event). Does it make sense?

[markkap]

Ok, maybe I just don't understand ;) AFAIK urls of the type .../wl_entity_type/event/ are the "front end" aka archive page for the event entity type, in this case, and not the entity itself. Adding SEO related settings to the entities themselves is much simpler, but plugins like yaost SEO do it already (just checked), and they will do it also for the entity type if we will make it accessible to the admin, which is why there is the first option.

For the entities themselves we can supply some basic SEO for titles and description, and integrate with yaost if it is installed. For the entity type, it is more of a structural/UX question, how do we expose the ability to manage that info.

[markkap]

Per the discussion with @cyberandy and @ziodave , the decision was to mimic the way wordpress expose the admin UI for taxonomies, while implementing our own logic in the display and form submission

[ziodave]

• unit tests
• labels:

• title and description are not updated in the page front-end:

• page's title lost the blog name:

• Wordlift_Seo_Service->description_meta doesn't consider that a meta description might already have been output by WP/theme?

[ziodave]

The following actions are pending here:

• Unit Tests
• Labels/Translations (we can review them during QA).