src/Resource/Entry.php issue related php's error_log

[payalord]

We are using older version of contentful SDK, but even in current master branch this problem is still exists.

contentful.php/src/Resource/Entry.php

Lines 460 to 482 in f464258

	/**
	* Initialize an entries tags.
	*
	* @param Tag[] $tags the tags to set
	*/
	public function initTags(array $tags)
	{
	$this->initContentfulTags($tags);
	// We need to check that the content type does not have a "tags" field, since we would otherwise shadow the
	// getter method used for that and possibly break existing code. Therefore, if we have that field, we emit a
	// warning and let the user fall back to the alternate method.
	if ($this->has('tags')) {
	error_log(
	"Warning: Content type '".
	$this->getType().
	"' has a field 'tags', which shadows Contentful tags. ".
	'You can call Entry::getContentfulTags() or change the field name to access them.'
	);
	$this->disableTags = true;
	} else {
	$this->disableTags = false;
	}
	}

As you can see here for type of "Warning" this code is using php's native error_log and there is no way to separate or control of the log level. In case if we don't wont to log warnings to keep log of errors clean on prod - we can't.

This is a really big problem for the huge site where a lot of traffic. Per one page let say landing page where will be pulled couple of entries on reach page load several times will be logged this WARNING message. And there is no way of suppressing it. Sure we can setup to clear log files or set it log per day and remove older log files etc. We can even filter out the warning message from log files to be finally able to see ONLY error messages, if we investigate any kind of problem on the site. But still this is so inflexible.

Can you consider of changing it to trigger_error with $error_level = E_USER_WARNING? In this case there will be possible to have more control over it. Or maybe to add some .env var to suppress error/warning messages to log by level or something like that?

Thanks

[Sebb767]

Hi @payalord ,

changing this to trigger_error seems reasonable, I'll implement this. Is it sufficient for you if I fix it in the most recent version or should I backport that fix to an older version and, if so, which one?