As you have clearly had this issue for over a year and this is the first report it must be caused by some extension or custom code on your own site

There is indead running some custom code on the site, but I doubt that this code is causing this problem. I suspect that maybe the site template might cause it. I cannot change this template, otherwise I could test that.

⁣------
Verzonden vanaf mijn mobiel
Met vriendelijke groet,
Peter Smits
Tel +31624234674
www.psmits.com
www.psmits.net

Verzonden door BlueMail ​

Op 24 aug. 2018 00:02, om 00:02, Brian Teeman notifications@github.com schreef:

As you have clearly had this issue for over a year and this is the
first report it must be caused by some extension or custom code on your
own site

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#21832 (comment)

I am sure you could switch the template for five minutes to test

I dont really see what you are expecting us to do here

The search view correctly assumes that created property is set
as it is a required property for a "common display"

Please notice the sentence below

The SQL must return the following fields that are used in a common display
routine: href, title, section, created, text, browsernav.

	/**
	 * Search content (articles).
	 * The SQL must return the following fields that are used in a common display
	 * routine: href, title, section, created, text, browsernav.
	 *
	 * @param   string  $text      Target search string.
	 * @param   string  $phrase    Matching option (possible values: exact|any|all).  Default is "any".
	 * @param   string  $ordering  Ordering option (possible values: newest|oldest|popular|alpha|category).  Default is "newest".
	 * @param   mixed   $areas     An array if the search it to be restricted to areas or null to search all areas.
	 *
	 * @return  array  Search results.
	 *
	 * @since   1.6
	 */
	public function onContentSearch($text, $phrase = '', $ordering = '', $areas = null)
	{

The developer of the plugin was probably testing with error_reporting off

Ask you system administrator to open all 3rd party plugins like
plugins/search/NNN/NNN.php

Locate method
public function onContentSearch(

and look if the SQL query is setting 'created' in the SQL
if not ... then report to the author of the search plugin

If the property is really non-applicable then this can be handled by the search view
but you need to patch SQL query (if within your skills)
e.g. like this

, "" AS created

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/21832

Thanks for reporting Issue, but as stated above closed as no Core-Issue.

Please ask help on the forums.

Hi All,

I have looked into the plugins/search/nnn, and every plugin does use "as created."
This is the SQL line in the plugin that searches the table
$query = 'SELECT c.'.$joodb->fid.' AS id, c.'.$joodb->ftitle.' AS title, c.'.$joodb->fcontent.' AS text ';
if (!empty($joodb->fdate)) $query .=', c.'.$joodb->fdate.' AS created ';
$query .= ' FROM '.$joodb->table.' AS c '

I cannot test this on the live site, so I would need to install a backup into a test environment.
Just for a change of one single line into the code.
I call this defensive programming, so why is this not applied as it has been proven to work properly

Just for a change of one single line into the code.

yes, you are right

the line at
components/com_search/views/search/view.html.php

if ($result->created)

could be made

if (!empty($result->created))

and everything will work the same
but the problem with such changes

• is that you will be hiding errors from ALL places that are supposed to have set the property

when you know that something is required to be set

then one should not put such code that hides the error when you turn error_reporting ON !
it is bad programming, it is not that people will not do it

but when we do it it should be considered a mistake on our part

in test environment you can do

if (!isset($result->created))
{
  echo '<pre>Missing title for: '; print_r($result->title);  '</pre>';
}

or in a production environment and being a little careful you could try writing the above and more info
to a log file

and probably find which plugin is doing this

also why not do if(!empty(...)) with all properties ?

why not start doing this everywhere that a property is required to be set
but some 3rd party plugin may have not set it,

please imagine if every code would start doing something like this ... people are trying to improve code quality not make it worst

maybe this is an edge case
and you could argue to the maintainers of this repository to change this code

Hi Georgios,

Thanks for the explenation, and you are correct that it is not a good idea to hide errors if someone did not follow the guidelines.

I have tested the issue with your code, but now no error is present ( so no indication)
Could this be a caching problem after updating "Joomla" ??
I cannot reproduce the error at this moment
This check is done in the code to format the date
if ($result->created)
{
$created = JHtml::('date', $result->created, JText::('DATE_FORMAT_LC3'));
}
So it seems to me that this might be a localisation problem after updating

Please open issue at
https://forum.joomla.org/
and i will answer your more there

Hi done that
But reported that I could not reproduce it anymore
That is incorrect the problem is still present with the original version
Also I do not get any output with your suggestion

The program has been altered, the issue is no longer present