I have updated to GL_2.1.2 and am finally getting around to restoring some of the portal blocks that I used successfully on the old the GL_1.8.1 site and cannot get any portal blocks to work no matter what I try.

I read through everything on this site about the subject (pretty sure) but have had no luck...

I know the feed URLs are good, it's just that I'm not getting the blocks I have created.

I have verified that PHP "allow_url_fopen" is yes/enabled and (of course) the "enabled" check boxes for the blocks are enabled. If I make the block a "normal" block it will show at a "hello world" level but if I make it a "portal block" it will vanish.

I am logging no errors and whenever I go back into the configuration for the missing block it will show a date/time value for "Last Feed Update"

It does not matter whether I try one of my site's own feeds or any number of remote feeds they just don't work.
Just for completeness here are a couple of the feeds that I am trying to display.

A Local Example: http://blogdogit.com/backend/BlogDogIt.rss
A Remote Example: http://feeds.feedburner.com/TheChroniclesOfRenard

I've tried Left -vs- Right and All -vs- Homepage Only; each with the same non-result.

I have swapped-in unmodified versions of the lib_custom.php and lib_common.php and only loose the functionality I expect, but still no "portal_blocks". The "php_function" Blocks are good and the "normal" Blocks are good.

It looks to me like I have my website configured to the extent this should work but I am open to learning where I might have screwed up. I sure would appreciate any suggestions...

There does seem to be a problem with the date check when displaying the block.

There also appears to be an issue with the block saving cache time with portal blocks.

I will look into this further.

I've created a bug report for it: https://github.com/Geeklog-Core/geeklog/issues/795

---

One of the Geeklog Core Developers.

Your issue should now be fixed. Please test: https://github.com/Geeklog-Core/geeklog/commit/2943b0218ad6659a1be1b31e85fca70e8a3c8f5e

Also if using https url with portal blocks, it could still fail as the following issue is not fixed yet: https://github.com/Geeklog-Core/geeklog/issues/732

---

One of the Geeklog Core Developers.

So I'm Not Crazy (well...)

Thanks Laugh

I will give it a go asap. (and report back.)
(not worried about https at this point but appreciate the heads-up.)


UPDATE: That worked for me Thanks again!

Okay let's assume for the sake of argument, I was wanting to get portal feeds via https...

After reviewing:
https://github.com/Geeklog-Core/geeklog/issues/732
it looks like there should be a way to make this work however, I am unclear as to whether I can get it going in the shared server environment at goDaddy.

according to phpinfo()
I do have cURL support enabled and OpenSSL/1.0.1e
but a check with:
Returns empty :/

I have created a php.ini file with the following:
but that seems to have done nothing for me (even after restarting the web process for my server to reload the new php5.ini file)

I did this after uploading a copy of https://curl.haxx.se/ca/cacert.pem to my site's $_CONF['path_data'] directory.

I was not sure if I needed to modify parserfactory.class.php or if that was an early work around? (when I tried that edit I got an error so i just moved away from that approach.)

I am finding that many wordpress sites are shoving port 443 onto port 80 requests so it looks like I will need to get https portals working sooner rather than later :/

Any enlightenment would be greatly appreciated.

No modification is needed. It should work with just:

openssl.cafile=/server/path/to/data/cacert.pem

set in the php.ini file. That is how I have it setup.

In the Geeklog Control Panel visit "Environment Check". This will tell you if OpenSSL extension is loaded. Then check the "Current PHP Settings" at the bottom of the page and do a quick page search for openssl.cafile to see if it actually was set for the website.

If it is not set, this may depend on how the host has php setup. Maybe you modified the wrong php.ini file (for different version of php, or another website, ...)

---

One of the Geeklog Core Developers.

See, that's what I thought...

Environment Check shows all "green lights" (with the exception of "skipped" graphics lib)
"Current PHP Settings" does not show openssl.cafile but I am pretty sure I am working with the correct php.ini file (actually named php5.ini)
If I rename the "loaded configuration file" to ~php5.ini and restart web service the phpinfo() shows the site reverts to the system default located file and site goes to default time zone setting. If I rename back to php5.ini and restart web service it shows as the "loaded configuration file" and my specified time zone change is picked up.
But still no sign of any change related to the addition of the openssl.cafile setting.
Do you suppose I need to be running an SSL enabled (https) site myself to portalize those sites I'm trying to do? (cuz that would suck...)

Thanks Laugh!

No your own site does not need to be https.

I would check with your web host. They may be blocking access to some php ini settings.

---

One of the Geeklog Core Developers.

I'll look into that and let you know.
Thank you, sir!

Okay, nothing like an explanation to explain things...

Called GoDaddy and they were very helpful - except they could not help me :/

It seems the openssl.capath and openssl.cafile settings were introduced with PHP_5.6 and I am running on PHP_5.4 (and will not get the opportunity to upgrade until late July - more than likely.)

So it looks like I can't get there from here (at least not today.) I'll revisit this when I can.

Thanks again, Laugh!

Glad to help and good to know re the PHP version.

Looking online it looks like while the php.ini setting may not exist in your php version it can still be set in code so the fix offered here about modifying FeedParserFactory::_getFeed

https://github.com/Geeklog-Core/geeklog/issues/732

should work.

---

One of the Geeklog Core Developers.

well...

when I apply that patch as indicated I get the error:


So maybe not

A line was missing try replacing:



with

---

One of the Geeklog Core Developers.

Thank you for that...

I knew instinctively the missing $req - request/method was the problem (I got mighty close in trying to hack-up a fix,) but there you prove once again it really helps to know what you are doing

So yes, that seems to work now; in that I can "portalize" https feeds. Oddly enough though, it does not seem to work for this site's feed: https://www.geeklog.net/backend/geeklog.rss

----

When placed in a portal block it displays the dreaded
There was a problem reading this feed (see error.log for details).

Which informs me:
1.) Unable to aquire feed reader for https://www.geeklog.net/backend/geeklog.rss

and from line 4241 lib-common::COM_formatBlock
4241 $retval .= COM_formatBlock($A, $_USER['noboxes']);

2.) Unable to parse XML Error Code: 4 Error Message: Not well-formed (invalid token)

----

But other than that, I am pleased with the productive results of this topic - I now have something else to play with

Hmmm, not sure why it would not work with Geeklog's feed. I tried the feed on 2 different sites and it works on them, but then they are using much newer versions of PHP. (and not the fix you applied)

---

One of the Geeklog Core Developers.

I just checked with your "Dating Sites Reviews" feed and that works just fine... seems to be something about this particular site - need to open a new ticket on that one and mark this one closed

Just a follow-up here...

I was getting annoyed with trying to get certain RSS Feeds working (mostly wordpress.com sites but even this website's feed [[url]https://www.geeklog.net/backend/geeklog.rss[/url]])

After revisiting this topic, I was reminded to check my environment (/admin/envcheck.php) and saw that I was still running PHP Version 5.4 - so I went to the GoDaddy hosting control panel for my site and (finally) had the option to update to version 5.6 (5.6.27 specifically) and now all my rss feeds are working like I thought they should.

So yeah, Happy New Year!

Glad you found the solution!

---

One of the Geeklog Core Developers.