lisabeewd

@dangoodman … no luck. All plugins updated to latest and still receiving an error 500 when trying to login on the check out page. Although the login appears to have actually happened before the 500 error was triggered I found that after hitting the ‘back’ button and moving to the cart page another 500 error occurs. I am moving the plugin back to a previous working version. Will follow up with our web host to see about getting our PHP version increased since it seems the PHP 5.3 is the culprit.

Hi @dangoodman … We were quickly trying to find a way to run the cart since we were in the middle of a sale so we just took the software back to a previous version. I installed the update manager and was able to stop the automatic updates.

We did have our web host make a couple of server setting changes but are not sure if they worked yet. Our sale just ended so we can update the plugin and see if there is still an error 500. I will be sure to get back to this post once we update (probably in a couple of days). If everything works well then I will let you know what server changes were made to fix the error 500.

BTW … We ARE running PHP 5.3 and are unable to update to a more recent version due to the server being shared with another website that cannot run under the updated Apache that would allow us to upgrade the PHP version for each account separately.

Thank you Dan!

Our web host is looking into the server settings and has advised they will set the RLimitCPU and RLimitMEM values for us. I will update your plugin to the latest version and give it a try when they are done.

I am not sure where the auto updating is coming from but it IS happening … every 12 hours. I suspect WordPress but it could also be our theme or Woothemes Helper since it is auto updating both Woocommerce and your plugin. So, I have installed a Disable Updates plugin and it has prevented the auto updating from occurring … so far.

I am also getting the following message in the plugins window:

The plugin weight-based-shipping-for-woocommerce/bootstrap.php has been deactivated due to an error: The plugin does not have a valid header.

Our hosting company has said the error 500 is being generated from your bootstrap.php program: the script is ending without headers being sent.

Thank you for responding, Frank. I understand the plugin allows us to hide areas for each role. Since we have not set our Contributors to hide the Users YET they are being hidden then it must be WordPress role capabilities that are hiding that area and not the plugin.

Hello? Is there any support for this plugin?

Aha … I think we discovered the problem. There seems to be a conflict with the WordPress HTTPS plugin. Once we deactivated the plugin, everything seemed to work fine.

I did check what is returned when using get_page_link() like you suggested. I found it returned HTTP even though the home and site urls were set to HTTPS. It seems the function actually returns the link based on the page protocol and when we deactivated the HTTPS plugin (which wasn’t actually allowing us to access the test page using HTTPS) and accessed the test page with that code using HTTPS then it returned the link with HTTPS.

It seems that the AI1EC plugin is not the one causing the issue. Thank you for responding so quickly to our inquiry!

Thank you Kasal for responding. It was not resolved and we simply removed them from the web page. I just put them back in and checked the source code and it does appear that the buttons are coming in with https … it is the link to hupso.com that is showing as http. That was throwing me off. Looks like there isn’t a problem with Hupso … there are others, though, that I will have to track down.

Thank you for responding to my post; it triggered me to go back and check and now we have some nice share buttons on our event page.

@esmi … Wow … didn’t consider myself hijacking the post. Was only trying to help. Please feel free to remove all my posts to this topic. I was able to correct the error with the suggestions I made (which I thought were very relevant to @peter’s post) but I guess you need to do it your way.

@tonioexp

Please forgive all my posts but I just found that

$pathtoplugin = plugin_dir_path(__FILE__ );

will give you the path to your plugin folder. I added it to the gallery-slider.php on my one installation that was getting the error and replaced the path references with the variable and the plugin runs without errors … so far. Yay!

Maybe you can go through your plugin and use the plugin_dir_path(__FILE__); code to get the server path to your plugin folder (it includes the trailing /) then those of us who have installed in subdirectories will be able to use your plugin! Which, by the way, works great!

Lisa

@tonioexp

Scratch my reference to plugins_url(); … that function doesn’t get the server path but the url path. There should be a function that will get you the server path to the plugins folder, though.

Lisa

@tonioexp

I installed your plugin on one of my client’s website and it runs perfectly with no errors. However, on another client’s website I run into the same errors described by Peter above.

The only difference between the two sites is that one is installed in the root directory and the other is installed in a subdirectory. In tracking the error I found your plugin is using $_SERVER[‘DOCUMENT_ROOT’] in your program gallery-slider.php when you are referring to the path for your register.txt file. The website I have installed in a subdirectory is the one showing the error because the subdirectory folder name is not in the document root.

You need to be referencing the WordPress function plugins_url() in order to get the path to the plugins folder. That would insure your plugin works for websites installed off the document root.

Lisa

Thank you Metaphorcreations! That makes sense! Good luck with Hostgator; I just moved away from them because my site kept going down.

Hi SgPlanwize, we ended up deleting your plugin then re-installing it and it seems to be working fine. We also have QuickCache installed and are wondering if that was playing a part in the issue. We have kept the QuickCache enabled but have it ‘refreshing’ more often and are watching to see it the Security Test Failed error begins showing again. For now it doesn’t appear as if it is a problem in your plugin; I believe something got out of sync when we moved the website and by re-installing your plugin, it was resolved.