Errors since upgrade to 1.1.0
Closed this issue · 33 comments
Since upgrading, I now get errors of "No date provided" and the partial appears three times instead of once in the sidebar. See here
My /partials/twigfeed.html.twig is
{% for title, feed in twig_feeds %}
<h4>{{ title }}</h4>
{% for item in feed %}
<h5>
<a href="{{ item.url }}">{{ item.title }}</a>
</h5>
<time>{{ item.date.date }}</time>
<p>{{ item.content }}</p>
{% endfor %}
{% endfor %}
Errors thrown by Twig in rendering the plugin specifically? What does your twigfeeds.yaml look like?
Ah. It appears that when I saved after updating, it updated '/localhost/config/plugins/twigfeeds.yaml' but not '/user/config/plugins/twigfeeds.yaml'
So, localhost version is:
enabled: true
twig_feeds:
-
source: 'https://vaviblog.com/content/all?_t=rss'
start: 0
end: 10
-
source: 'http://feeds.bbci.co.uk/news/uk/rss.xml'
start: 0
end: 2
-
source: 'http://www.aljazeera.com/xml/rss/all.xml'
Which would explain why I am seeing it repeated three times, but not the 'No date provided" error.
user version is unchanged from before update:
enabled: true
twig_feeds:
-
source: 'https://vaviblog.com/content/all?_t=rss'
start: 0
end: 10
I tried using your feed, like this:
enabled: true
twig_feeds:
-
source: 'https://vaviblog.com/content/all?_t=rss'
start: 0
end: 10
-
source: 'http://feeds.bbci.co.uk/news/uk/rss.xml'
start: 0
end: 2
-
source: 'http://www.aljazeera.com/xml/rss/all.xml'
Both with and without the Grav-cache enabled, both without issue.
Where does the "No date provided"-error appear? Does the screen say "Whoops, something went wrong" with a colorful page - like when Grav throws a Twig-error? Does it simply log to PHP's error_log? Or is there a rendered error saying "Twig Feeds-plugin: Vendor-package PicoFeed threw an exception, check error logs."?
The error appears in the rendered HTML. Here's a screen grab from a few minutes ago.
Do you get the same results both on live and on local? My first thought is that this is because of an issue with cURL on the server in question, of which there are some good ways of debugging. The first step is to check Picofeeds cURL access. Enter the user/plugins/twigfeeds-folder, and run this:
php vendor/fguillot/picofeed/picofeed feed http://rss.nytimes.com/services/xml/rss/nyt/World.xml
The output will be an iteration of all the items in the feed. If it is not, the output helps us ascertain where the error lies. So if that fails to show a whole bunch of parsed RSS-items, run this:
php vendor/fguillot/picofeed/picofeed debug http://rss.nytimes.com/services/xml/rss/nyt/World.xml
If cURL fails, there will be an error like this: [8] => [2014-11-08 14:04:16] PicoFeed\Client\Curl cURL error: .... Finally, we can check that the necessary requirements are indeed loaded and available to PHP, and that they are not silently ignored in run-time. In the same folder, create a file called debug.php, and paste this into it:
<?php
if( ini_get('allow_url_fopen') ) {
print('Success: allow_url_fopen is enabled.' . "\n");
} else {
print('Failure: allow_url_fopen is disabled.' . "\n");
}
if (extension_loaded('dom')) {
print('Success: DOM-extension is loaded.' . "\n");
} else {
print('Failure: DOM-extension is not loaded.' . "\n");
}
if (extension_loaded('SimpleXML')) {
print('Success: SimpleXML-extension is loaded.' . "\n");
} else {
print('Failure: SimpleXML-extension is not loaded.' . "\n");
}
?>
Now run it with php debug.php. The output of all this will greatly aid in ensuring the next version of this plugin can safeguard against such silent errors, though I would commonly expect them to have already been been thrown by the library.
Same result live and local.
It worked beautifully before the upgrade, so doubt it was server issues. Will now try your debug suggestions locally.
That first test failed. Here's the result:
[15:20:58 - 17-01-26] /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds % php vendor/fguillot/picofeed/picofeed feed http://rss.nytimes.com/services/xml/rss/nyt/World.xml
Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php:693
Stack trace:
#0 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php(693): DateTime->__construct('+604800 seconds')
#1 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php(225): PicoFeed\Client\Client->parseExpiration(Object(PicoFeed\Client\HttpHeaders))
#2 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fgui in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoF[15:21:26 - [1[15:[15:[1[15:[1[1[1[1[1[1[1[1[15:[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1[1
The second php thing also fails with the same error as above.
debug.php gives this output, no failures:
Success: allow_url_fopen is enabled.
Success: DOM-extension is loaded.
Success: SimpleXML-extension is loaded.
So, I guess the error message is pretty specific, but I don't know enough php to be able to try a fix. Sorry.
I think I may have a solution, according to the error. As the third test showed, the necessary requirements for the vendor-library are in place, but functionally the error should have been thrown in the earlier version as well. If you replace the contents of your current twigfeeds.php with this:
<?php
namespace Grav\Plugin;
use Grav\Common\Data;
use Grav\Common\Plugin;
use Grav\Common\Grav;
use Grav\Common\Uri;
use Grav\Common\Taxonomy;
use Grav\Common\Page\Page;
use RocketTheme\Toolbox\Event\Event;
use RocketTheme\Toolbox\File\File;
require __DIR__ . '/vendor/autoload.php';
use PicoFeed\Reader\Reader;
use PicoFeed\Config\Config;
use PicoFeed\PicoFeedException;
class TwigFeedsPlugin extends Plugin
{
public static function getSubscribedEvents() {
return [
'onTwigSiteVariables' => ['onTwigSiteVariables', 0]
];
}
public function onTwigSiteVariables(Event $event) {
if (!$this->isAdmin()) {
$pluginsobject = (array) $this->config->get('plugins');
$pluginsobject = $pluginsobject['twigfeeds'];
if (isset($pluginsobject) && $pluginsobject['enabled']) {
if (is_array($pluginsobject['twig_feeds'])) {
$items = array();
foreach ($pluginsobject['twig_feeds'] as $feed) {
try {
$config = new Config;
$config->setTimezone('UTC');
$reader = new Reader($config);
$resource = $reader->download($feed['source']);
$parser = $reader->getParser(
$resource->getUrl(),
$resource->getContent(),
$resource->getEncoding()
);
$result = $parser->execute();
$title = $result->getTitle();
$source = $feed['source'];
if (isset($feed['name'])) {
$name = $feed['name'];
} else {
$name = $title;
}
if (isset($feed['start'])) {
$start = $feed['start'];
} else {
$start = 0;
}
if (isset($feed['end'])) {
$end = $feed['end'];
} else {
$end = 500;
}
if (isset($feed['start']) && isset($feed['end'])) {
$amount = abs($start-$end);
} else {
$amount = count($result->items);
}
$items[$name]['title'] = $title;
$items[$name]['source'] = $source;
$items[$name]['start'] = $start;
$items[$name]['end'] = $end;
$items[$name]['amount'] = $amount;
foreach ($result->items as $item) {
$items[$name]['items'][] = $item;
if (++$start == $end) break;
}
}
catch (PicoFeedException $e) {
$this->grav['debugger']->addMessage('PicoFeed threw an exception: ' . $e);
}
catch (Exception $e) {
$this->grav['debugger']->addMessage('Twig Feeds-plugin threw an exception: ' . $e);
}
}
$this->grav['twig']->twig_vars['twig_feeds'] = $items;
}
}
}
}
}
It should resolve the exception by explicitly declaring a default timezone, but also improve the clarity of any other errors.
I did as suggested and continue to get the same error. I ran the commands you suggested again, and the error seems to me to be the same:
Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php:693
Stack trace:
#0 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php(693): DateTime->__construct('+604800 seconds')
#1 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php(225): PicoFeed\Client\Client->parseExpiration(Object(PicoFeed\Client\HttpHeaders))
#2 /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fgui in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/vendor/fguillot/picofeed/lib/PicoFeed/Client/Client.php on line 693
I see that you also added debug information. Here's the output, at least for the first item, which shows that the feed is being fetched:
array:3 [
"Jeremy Cherfas" => array:6 [
"title" => "Jeremy Cherfas"
"source" => "https://vaviblog.com/content/all?_t=rss"
"start" => 0
"end" => 10
"amount" => 10
"items" => array:10 [
0 => PicoFeed\Parser\Item {#784
+rtl: array:8 [
0 => "ar"
1 => "fa"
2 => "ur"
3 => "ps"
4 => "syr"
5 => "dv"
6 => "he"
7 => "yi"
]
+id: "1354000f1ea26140b8ea0610ceefb429ff47706f8cffacb5774eecc8eca33b1f"
+title: "Nick Drake's #frangipani"
+url: "https://vaviblog.com/2017/nick-drakes-frangipani"
+author: "Jeremy Cherfas"
+date: DateTime {#788
+"date": "2017-01-27 09:18:31.000000"
+"timezone_type": 1
+"timezone": "+00:00"
}
+publishedDate: DateTime {#788}
+updatedDate: DateTime {#788}
+content: """
<p>\n
<a href="https://vaviblog.com/file/9c959596249b64f4457b26c16d29ee41/igAsKlxW.jpg" rel="noreferrer" target="_blank"><img src="https://vaviblog.com/file/edd42b3d8890a9c038b75ddca8a92e41/thumb.jpg"/></a>\n
</p>
"""
+enclosureUrl: "https://vaviblog.com/file/9c959596249b64f4457b26c16d29ee41/igAsKlxW.jpg"
+enclosureType: "image/jpeg"
+language: ""
+xml: SimpleXMLElement {#768
+"title": "Nick Drake's #frangipani"
+"link": "https://vaviblog.com/2017/nick-drakes-frangipani"
+"guid": "https://vaviblog.com/2017/nick-drakes-frangipani"
+"pubDate": "Fri, 27 Jan 2017 09:18:31 +0000"
+"author": "Jeremy Cherfas"
+"description": SimpleXMLElement {#863}
+"enclosure": SimpleXMLElement {#860
+"@attributes": array:3 [
"url" => "https://vaviblog.com/file/9c959596249b64f4457b26c16d29ee41/igAsKlxW.jpg"
"type" => "image/jpeg"
"length" => "90116"
]
}
}
+namespaces: array:2 [
"itunes" => "http://www.itunes.com/dtds/podcast-1.0.dtd"
"atom" => "http://www.w3.org/2005/Atom"
]
}
Hope this helps
It does tremendously: There might be an issue with your php.ini, and particularly whether the right .ini is being used. If you replace the contents of the debug.php we created previously with this:
<?php
if (date_default_timezone_get()) {
print 'date_default_timezone_set: ' . date_default_timezone_get() . "\n";
} else {
print 'no date_default_timezone_set retrievable' . "\n";
}
if (ini_get('date.timezone')) {
print 'date.timezone: ' . ini_get('date.timezone') . "\n";
} else {
print 'no date.timezone set in php.ini' . "\n";
}
?>
Then run it, what output do you get? We are expecting something like this:
date_default_timezone_set: UTC
no date.timezone set in php.ini
If the first one fails, we might be able to circumvent DateTime's error simply by declaring the timezone prior to running the parser with the updated configuration.
Interesting! As you predicted, there's a warning.
[12:38:19 - 17-01-27] /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds % php debug.php
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 2
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 3
date_default_timezone_set: UTC
no date.timezone set in php.ini
Right, we want to correct this lapse in judgement from the server, and edit user/plugins/twigfeeds/twigfeeds.php again:
<?php
namespace Grav\Plugin;
date_default_timezone_set('UTC');
ini_set('date.timezone', 'UTC');
use Grav\Common\Data;
use Grav\Common\Plugin;
use Grav\Common\Grav;
use Grav\Common\Uri;
use Grav\Common\Taxonomy;
use Grav\Common\Page\Page;
use RocketTheme\Toolbox\Event\Event;
use RocketTheme\Toolbox\File\File;
require __DIR__ . '/vendor/autoload.php';
use PicoFeed\Reader\Reader;
use PicoFeed\Config\Config;
use PicoFeed\PicoFeedException;
class TwigFeedsPlugin extends Plugin
{
public static function getSubscribedEvents() {
return [
'onTwigSiteVariables' => ['onTwigSiteVariables', 0]
];
}
public function onTwigSiteVariables(Event $event) {
if (!$this->isAdmin()) {
$pluginsobject = (array) $this->config->get('plugins');
$pluginsobject = $pluginsobject['twigfeeds'];
if (isset($pluginsobject) && $pluginsobject['enabled']) {
if (is_array($pluginsobject['twig_feeds'])) {
$items = array();
foreach ($pluginsobject['twig_feeds'] as $feed) {
try {
$config = new Config;
$config->setTimezone('UTC');
$reader = new Reader($config);
$resource = $reader->download($feed['source']);
$parser = $reader->getParser(
$resource->getUrl(),
$resource->getContent(),
$resource->getEncoding()
);
$result = $parser->execute();
$title = $result->getTitle();
$source = $feed['source'];
if (isset($feed['name'])) {
$name = $feed['name'];
} else {
$name = $title;
}
if (isset($feed['start'])) {
$start = $feed['start'];
} else {
$start = 0;
}
if (isset($feed['end'])) {
$end = $feed['end'];
} else {
$end = 500;
}
if (isset($feed['start']) && isset($feed['end'])) {
$amount = abs($start-$end);
} else {
$amount = count($result->items);
}
$items[$name]['title'] = $title;
$items[$name]['source'] = $source;
$items[$name]['start'] = $start;
$items[$name]['end'] = $end;
$items[$name]['amount'] = $amount;
foreach ($result->items as $item) {
$items[$name]['items'][] = $item;
if (++$start == $end) break;
}
}
catch (PicoFeedException $e) {
$this->grav['debugger']->addMessage('PicoFeed threw an exception: ' . $e);
}
catch (Exception $e) {
$this->grav['debugger']->addMessage('Twig Feeds-plugin threw an exception: ' . $e);
}
}
$this->grav['twig']->twig_vars['twig_feeds'] = $items;
}
}
}
}
}
That is, we add date_default_timezone_set('UTC'); and ini_set('date.timezone', 'UTC'); after the initial namespace-declaration. This is a rather dirty approach, and in the next version I'll add it as a fallback rather than a forced setting.
Does this change help suppress the error?
Nope, alas.
Still getting the error in the HTML, and debug.php also still gives the same message. Here's the output:
[13:09:56 - 17-01-27] /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds % php debug.php
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 2
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 3
date_default_timezone_set: UTC
no date.timezone set in php.ini
I have caching off, and just for good measure I cleared the cache first. :)
Then PHP is not respecting the ini_set-declaration. Could you check your php.ini to see what date.timezone is set to?
For reference, to check whether PHP allows us to set settings on the fly, we could run this debug.php:
<?php
if (date_default_timezone_get()) {
print 'date_default_timezone_set: ' . date_default_timezone_get() . "\n";
} else {
print 'no date_default_timezone_set retrievable, setting it now' . "\n";
date_default_timezone_set('UTC');
if (date_default_timezone_get()) {
print 'date_default_timezone_set: ' . date_default_timezone_get() . "\n";
} else {
print 'Still could not apply date_default_timezone_set' . "\n";
}
}
if (ini_get('date.timezone')) {
print 'date.timezone: ' . ini_get('date.timezone') . "\n";
} else {
print 'no date.timezone set in php.ini, setting it now' . "\n";
ini_set('date.timezone', 'UTC');
if (ini_get('date.timezone')) {
print 'date.timezone: ' . ini_get('date.timezone') . "\n";
} else {
print 'Still could not apply ini_set' . "\n";
}
}
?>
From php.ini:
[Date]
; Defines the default timezone used by the date functions
; Will be changed by MAMP to system timezone
date.timezone = "Europe/Berlin"
Could that be the problem, that MAMP changes to system timezone? But that would not explain why it also throws an error in the production install.
I'll try the debug now.
This is the output of the debug:
[14:20:24 - 17-01-27] /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds % php debug.php
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 2
Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 3
date_default_timezone_set: UTC
no date.timezone set in php.ini, setting it now
date.timezone: UTC
This is quite odd, as "Europe/Berlin" is a valid setting for date.timezone in php.ini, and is initially assumed by both PHP and the script. Despite now having set this explicitly, and the last debug shows us that PHP accepts the on-the-fly settings, a warning is still thrown.
This does point us in a further direction. The error is not specific to the plugin, but general to the installation of PHP. Otherwise, debug.php would not also be throwing it. One thing to check is whether the CLI is using the same php.ini as executed scripts. If you run the command php -i | grep "php.ini", what returns as Loaded Configuration File? Mine is C:\caddy\php\php.ini, which is the only one available for that installation of PHP. Many installations of PHP juggle .ini's for different functionality, including MAMP.
Another thing to check is whether the actual server is interfering with PHP. For example, Apache's .htaccess can use php_value date.timezone or SetEnv TZ (See SO-answer) to do this, though arguably it is uncommon to force this upon scripts.
As I say, this should not matter. We've already declared an acceptable timezone with "UTC", and the PicoFeed-library can return correct results without this. My PHP, for example, does not have a timezone set (in php.ini, it is ;date.timezone =). Even with error_reporting = E_ALL, the warning is not thrown.
The problem may be with how strictly PHP interprets these timezones (likely due to a specific .ini or version). Generally, a regular string in quotes will work regardless, but to rule out problems you can try changing the php.ini-declaration to date.timezone = Europe/Berlin or date.timezone = UTC (either without the double-quotes, ref). This should not work in debug.php as UTC will be interpreted as a undefined constant.
[14:21:27 - 17-01-27] /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds % php -i | grep "php.ini"
Configuration File (php.ini) Path => /etc
Does this mean it is not using the MAMP PHP? Because that's where I have been looking.
I cannot see anything in .htaccess that is setting anything to do with time or date.
I'll try editing the php.ini in a little while, because I have some work I must finish now.
Configuration File (php.ini) Path => /etc means that PHP is looking for a php.ini from the /etc-folder. If you change debug.php to:
<?php
phpinfo();
?>
You would get several indications of what .ini is in use: Configuration File (php.ini) Path, Loaded Configuration File, Scan this dir for additional .ini files, and Additional .ini files parsed. This is because php.ini is searched for in order of priority.
What matters is the Loaded Configuration File, which tells us what php.ini is actually loaded to run the script we're executing (and should edit, if necessary). This all relates to how MAMP is set up, and there's potentially a chance that an incorrectly formatted or interpreted date.timezone-value throws the warning.
Configuration File (php.ini) Path => /etc
Loaded Configuration File => (none)
Scan this dir for additional .ini files => /Library/Server/Web/Config/php
Additional .ini files parsed => (none)
Maybe I should also try getting the phpinfo from the live site.
That would help. The above also indicates that the php.ini is indeed in /etc or in the prioritized hierarchy.
Now this is interesting. I ran the first debug you gave me on the live site, and it returned th array of feed variables, no problem, no warnings.
But the stream errors persist. Now trying to get phpinfo.
This is from the live site:
Configuration File (php.ini) Path => /etc/php55
Loaded Configuration File => /etc/php55/php.ini
Scan this dir for additional .ini files => /etc/php55/conf.d
Additional .ini files parsed => /etc/php55/conf.d/imagick.ini,
/home/jcgrav/.php/5.5/phprc
And this from the live site:
[ben-hill]$ php debug.php
date_default_timezone_set: America/Los_Angeles
date.timezone: America/Los_Angeles
Not sure what else I can do, and I am conscious I am taking a lot of your time.
I guess nobody else is having this issue.
Oh I'm just working on the cache-functionality for the plugin, which is quite a beast compared to the simplicity of the current version; my head is already in full PHP-mode.
In the live site's php.ini, check whether date.timezone is set as date.timezone = America/Los_Angeles (without quotes, not commented out - and potentially if this is set by .htaccess) and whether this differs from the local php.ini (currently presumed in /etc). Also, check the values of error_reporting in both .ini's - if one suppresses them but the other does not, it may reveal why the warnings are thrown.
Live site has date.timezone => America/Los_Angeles => America/Los_Angeles
Local site has date.timezone => no value => no value
There are other differences too. Local site has
date
date/time support => enabled
"Olson" Timezone Database Version => 2015.5
Timezone Database => internal
Warning: phpinfo(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /Applications/MAMP/htdocs/grav-blog/user/plugins/twigfeeds/debug.php on line 2
Default timezone => UTC
Directive => Local Value => Master Value
date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => no value => no value
Live site does not have that error warning
date
date/time support => enabled
"Olson" Timezone Database Version => 2015.5
Timezone Database => internal
Default timezone => America/Los_Angeles
Directive => Local Value => Master Value
date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => America/Los_Angeles => America/Los_Angeles
But I get the errors local and live.
Error_reporting
Live error_reporting => 22519 => 22519
Local error_reporting => no value => no value
22519 is equivalent to E_ALL ^ E_NOTICE ^ E_DEPRECATED, though since the error persists between local and live it should not strictly matter. Though, since local does indeed throw warnings I suspect some setting is overriding this. There is something genuinely odd about this error, as it it inherent to the system/PHP-setup, not the plugin itself. You are using MAMP on OSX, right?
@jeremycherfas with v1.2.0, do you still get any errors about DateTime?
Yes, I still get the errors. I left the plugin live on my site so you can see.
I also have another error, which is that the plugin is displaying 6 items, not 10. I copied the debug dump in case this helps.
Ok, here's an update: Because of an error with list-fields in Grav currently (v1.1.12-1.1.15 at least), we need the declarative name-syntax in the for-loop: {% for name, feed in twig_feeds if name == 'Jeremy Cherfas' %}. Otherwise the plugin-defaults will also be included (Al Jazeera and BBC).
Further, I think you were/are using the initial syntax for the plugin. Testing with this, newer syntax:
<div class="sidebar-content">
<h4><a href="https://vaviblog.com" title="Microblogish stuff">Stream</span></a></h4>
{% for name, feed in twig_feeds if name == 'Jeremy Cherfas' %}
{% for item in feed.items %}
<p>
<time>{{ item.date.date|nicetime(false) }}</time>
<a href="{{ item.url }}">{{ item.title }}</a>
</p>
{% endfor %}
{% endfor %}
</div>
I get 10 items returned, with dates formatted as "time ago". This is with this config in /user/config/plugins/twigfeeds.yaml:
enabled: true
twig_feeds:
-
source: 'https://vaviblog.com/content/all?_t=rss'
start: 0
end: 10
Which gives this output, using the latest version of MAMP on Windows with PHP 7.0.9:
Hurrah!
Using the changed syntax for the partial and plugin 1.2 (Grav 1.1.14) your plugin now works perfectly. About to push to the live site.
Thank you for your help and patience.
No problem at all, glad it got sorted out.