Support Forum
I am on a shared host with Network Solutions. Recently we have noticed that anyone accessing the forum RSS entity (Group and All) is receiving the following warning.
XML Parsing Error: junk after document element
Location: http://www.exploristforum.com/.....8a49c2185/
Line Number 2, Column 1:<b>Warning</b>: getimagesize() [<a href='function.getimagesize'>function.getimagesize</a>]: http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in <b>/data/0/0/23/9/23824/user/24314/problem-with-post-edit-buttontdocs/exploristX10/wp-content/plugins/simple-press/sp-api/sp-api-filters.php</b> on line <b>1436</b><br />
^
Contacted Network Solutions Tech Team and they told me that the call "allow_url_fopen=0" is a problem because of hackers. We are asking them how to disable it .. but so far no help.
Any Suggestions or solutions.
Thanks,
Ed
Yellow Swordfish said
Are you using version 5.4.1 of Simple:Press? There was an update to this in that version that bypassed the call to getimagesize() if allow_url_fopen was turned off. At least it worked well in testing...
YS, Yes... we are using 5.4.1 .. is it possible that it installed incorrectly?
The feature was working great on 5.4 until we installed 5.4.1...
PS .. we are using Wordpress 3.6 .. as we do not trust 3.8.1 until further testing.
Ed
Edward J Gelb said
Yellow Swordfish said
Are you using version 5.4.1 of Simple:Press? There was an update to this in that version that bypassed the call to getimagesize() if allow_url_fopen was turned off. At least it worked well in testing...YS, Yes... we are using 5.4.1 .. is it possible that it installed incorrectly?
The feature was working great on 5.4 until we installed 5.4.1...
PS .. we are using Wordpress 3.6 .. as we do not trust 3.8.1 until further testing.
Ed
YS, More information that may be of help to you.
In some cases a Group RSS will work. In other instances, a TOPIC RSS will work but not the FORUM RSS or GROUP RSS.
Does this help your analysis?
Ed
To be honest the main analysis needed here is to try and fathom why you get the message and others do not! While I appreciate the getimagesize() function requires allow_url_fopen it does not, in my experience, usually result in a warning being issued and displayed to the screen. And we will come back to that in a moment.
I can offer you a temporary fix if you are up to make a couple of minor code edits. And then meanwhile we can discuss it here on whether to make those permanent. Let me know if this appeals.
There are two points here. The first is that there would be no need to make the call to getimagesize() - which we would prefer not to do anyway - if images were inserted into forum posts in a fully valid way. The reason the call is made is because images are getting inserted in posts with no dimensional information. SP needs to know the image width to enable it to function properly and if the width is missing from the image tag it makes a call to find the size.
The second - and the one I wanted to mention - is that it is recommended by everyone, everywhere (with the possible exception of your hosting company!) that php 'Notice' and 'Warning' messages are turned off on production sites. As you will see from the message ( a 'Warning') it displays the full path to your server which is not something you really want to make public. These sort of messages should be logged to an error log file but should never be displayed on a live site and I would personally be having string words with your host top that effect.
YELLOW
SWORDFISH
|
Yellow Swordfish said
To be honest the main analysis needed here is to try and fathom why you get the message and others do not! While I appreciate the getimagesize() function requires allow_url_fopen it does not, in my experience, usually result in a warning being issued and displayed to the screen. And we will come back to that in a moment.I can offer you a temporary fix if you are up to make a couple of minor code edits. And then meanwhile we can discuss it here on whether to make those permanent. Let me know if this appeals.
There are two points here. The first is that there would be no need to make the call to getimagesize() - which we would prefer not to do anyway - if images were inserted into forum posts in a fully valid way. The reason the call is made is because images are getting inserted in posts with no dimensional information. SP needs to know the image width to enable it to function properly and if the width is missing from the image tag it makes a call to find the size.
The second - and the one I wanted to mention - is that it is recommended by everyone, everywhere (with the possible exception of your hosting company!) that php 'Notice' and 'Warning' messages are turned off on production sites. As you will see from the message ( a 'Warning') it displays the full path to your server which is not something you really want to make public. These sort of messages should be logged to an error log file but should never be displayed on a live site and I would personally be having string words with your host top that effect.
YS, I am willing to make the code edits. Please send me the required information to my email address and I will be happy to test them out.
In the meantime, you are always welcome to enter the website as the messages also would appear to guests.
Ed
I did visit. And quite seriously - getting the warning messages off you site is the most important thing. The more I think about it the more appalled I am that a host can be picky about something like allow_url_fopen (which most do not turn off) yet allow messages like this to be displayed publicly.
OK - to the edits.
The file in question is /simple-press/sp-api/sp-api-filters.php.
There are 3 calls to the getimagesize() function in this file - current lines numbe4rs are, I believe, 829, 1436 and 1724.
I think as as a temporary measure it would be worth prefixing these with the @ symbol, as in @getimagesize() which suppresses the warning message.
YELLOW
SWORDFISH
|
Edward J Gelb said
Yellow Swordfish said
To be honest the main analysis needed here is to try and fathom why you get the message and others do not! While I appreciate the getimagesize() function requires allow_url_fopen it does not, in my experience, usually result in a warning being issued and displayed to the screen. And we will come back to that in a moment.I can offer you a temporary fix if you are up to make a couple of minor code edits. And then meanwhile we can discuss it here on whether to make those permanent. Let me know if this appeals.
There are two points here. The first is that there would be no need to make the call to getimagesize() - which we would prefer not to do anyway - if images were inserted into forum posts in a fully valid way. The reason the call is made is because images are getting inserted in posts with no dimensional information. SP needs to know the image width to enable it to function properly and if the width is missing from the image tag it makes a call to find the size.
The second - and the one I wanted to mention - is that it is recommended by everyone, everywhere (with the possible exception of your hosting company!) that php 'Notice' and 'Warning' messages are turned off on production sites. As you will see from the message ( a 'Warning') it displays the full path to your server which is not something you really want to make public. These sort of messages should be logged to an error log file but should never be displayed on a live site and I would personally be having string words with your host top that effect.
YS, I am willing to make the code edits. Please send me the required information to my email address and I will be happy to test them out.
In the meantime, you are always welcome to enter the website as the messages also would appear to guests.
Ed
YS, Please forgive my manners, I forgot to say "Thank You!!"
E
Yellow Swordfish said
No worries!But please do let us know if those edits worked for you.
Problem .. lines 1731 $size = @getimagesize (str_replace ... produces error in
Parse error: syntax error, unexpected T_VARIABLE in /data/wp-content/plugins/simple-press/sp-api/sp-api-filters.php on line 1736
Removal of @ in line 1731 produces error
Parse error: syntax error, unexpected T_VARIABLE in /data/wp-content/plugins/simple-press/sp-api/sp-api-filters.php on line 1736
Ed
1 Guest(s)