The Schema.org plugins are great.
I have noticed that the data for a job posting, for example, is not stored as an article property.
$this->item->schema
That's a pity because I could process the information directly in an article override and display it in the frontend.
That would be great and I wouldn't need a database query to display the information from the schema plugins.
What Do you think?
I hope I have expressed myself reasonably clearly.
Labels |
Added:
No Code Attached Yet
|
A real sustainable solution would be to use the content from custom fields as the data source and to transfer the data to the schema plugins. A mix of dynamic values and fixed values.
Hi Guys,
I am aware that the JSON is generated.
I am interested in data economy. If I have the data in the database, I can also use it on different tasks.
Something like this:
use Joomla\Database\ParameterType;
$db = Factory::getContainer()->get('DatabaseDriver');
$itemId=$this->item->id;
$query = $db->getQuery(true);
$query->select('*')
->from($db->quoteName('#__schemaorg'))
->where($db->quoteName('itemId') . '= :itemId')
->bind(':itemId', $itemId, ParameterType::INTEGER);
$db->setQuery($query);
$jobresults = $db->loadObjectList();
if(!empty($jobresults)) {
$job = json_decode($jobresults[0]->schema);
}
and later
<dl class="dl-horizontal">
<?php
echo '<dt>' .Text::_('JOBTITLE'). '</dt><dd>'. $job->title . '</dd>';
echo '<dt>' .Text::_('JOBDESCRIPTIOB'). '</dt><dd>'. $job->description . '</dd>';
echo '<dt>' .Text::_('JOBDATE'). '</dt><dd>'. $job->datePosted . '</dd>';
echo '<dt>' .Text::_('JOBLOCATIONTYPE'). '</dt><dd>'. $job->jobLocationType . '</dd>';
echo '<dt>' .Text::_('JOBTYPE'). '</dt><dd>'. $job->employmentType . '</dd>';
echo '<dt>' .Text::_('JOBSTARTDATE'). '</dt><dd>'. $job->jobStartDate->value . '</dd>';
echo '<dt>' .Text::_('JOBKONTAKTMAIL'). '</dt><dd>'. $job->hiringOrganization->email . '</dd>';
?>
I think the data for displaying is the job of custom fields, not schema data, thus you would need to write the code if you want to re-use that data for displaying purpose. Ideally, It would be great if it could work as @tecpromotion described above, but that's another discussion.
A real sustainable solution would be to use the content from custom fields as the data source and to transfer the data to the schema plugins. A mix of dynamic values and fixed values
Actually, schema plugins are nothing more than predefined custom fields, right?
That's right, but it is designed to use for different purpose, not for displaying (at least I believe that).
A real sustainable solution would be to use the content from custom fields as the data source and to transfer the data to the schema plugins. A mix of dynamic values and fixed values.
agree
That would make sense, but would certainly be complicated.
You could perhaps select which type of schema this group should correspond to when creating a field group.
And when creating the fields, the property can then be selected accordingly.
The plugin would then have to check if I have a corresponding field group and then output the JSON.
I think this procedure could become complicated, as it is very error-prone and requires the user to be familiar with the handling of the schema
Labels |
Added:
Feature
|
I convert this to a discussion to define the request in more detail.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-04-11 15:28:31 |
Closed_By | ⇒ | rdeutz |
Hi @angieradtke
The data managed by schema plugins is just uses to describe our content and is injected to the head tag of the page in JSON+LD format automatically by the plugins.
It is not used for displaying purpose, so the data is won't be available as you expect. If you want to use it for your own purpose, you would need to write code query the data from database.