oooorgle

These are the header fields as of version 0.2.1.
quote|first_name|last_name|source|img_url

Mainly the import feature is to restore an already exported backup of the quotes database, however it is possible and seemingly very practical if you already have your quotes in a spreadsheet or such format.

Perhaps as an example to help refer to, you could enter a few quotes into the plugin and perform an export. Then refer to that export files structure as a reference or template. I expect that will work if formatted correctly. Character encoding, if you use copy/paste, can sometimes cause a problem (apostrophes and such). I have some basic error reporting on import that should tell you what line in the file, if there is an error in the formatting. Hope this helps and love to hear how it goes for you. Thanks!

Release 0.2.1 includes the above changes along with the re-enabled widget class. I will leave this open for a time in hopes I am able to further address the issues presented here.

I removed the function in question, replacing it with a $_REQUEST. Why I didn’t do that before is one of my doh’s! I had it running on every page instead of only searches where it is needed. Hopefully this corrects that warning. If you would be so kind as to give it another shot, same link. Thanks!

Ok, I now have removed the widget init. Please use same link above to try again. At the very least it shouldn’t throw the same error. Thanks!

This time I have updated the 0.2.1 widget class’s parent constructor to it basic arguments and provided a static name instead of having the function generate one (please use same link above).

If this fails then perhaps I will remove the widget class from the plugin to see if the page and gallery works for you, if not then at least it will give more detail with the new error code returned. I am in your debt for helping me troubleshoot this, thanks again.

I have updated how the plugin registers the sidebar widget class and think perhaps this is what is causing the conflict. Would you be willing to test this for me?

https://oooorgle.com/plugins/wp/quotes-llama/quotes-llama_0.2.1.zip

I would be very grateful as I don’t have an environment like yours to check myself. Otherwise I can post a release that includes this change and you can get it that way. Thanks!

Hi runoiz, that message from the fastcgi server usually means that it was not found or inaccessible as a file on its filesystem. Please verify that the plugin files are there and the filesystem can access them. If it happens to be a conflict with another plugin can you provide what plugins you are running along with this one?

I think it is a conflict with nginx but I need to do more research. Hopefully I can figure this out sooner than later. Thanks for providing more information!

You are very welcome.

I’d prefer to keep the troubleshooting within this support thread so others can benefit from it as well. Could you list what plugins you are using? I am betting there is some conflict with another plugin that I am not aware of yet. Thanks.

Version 0.2 uploaded. If you would, let me if this is what you were looking for and how you like it. Feel free to offer suggestions.

Very sorry to hear that it caused you problems. This is the first notice I have received of it causing this type of problem. Have you updated to the most recent version? Would you might be able to provide some more detail to help me troubleshoot like plugins you use and version information. Did it give a specific error or how exactly did it “crash your site”?

Hi wolfleader, I will work that into the next release. Had that on my mind already so perhaps in the next week or so when I can make time to work on it. Thanks for the suggestion!

Version 0.6 is now available which includes the filename fix.

I am completely new to ModSecurity and OWASP. I do wonder, are you using CPanel to manage your hosting? I am and I don’t see anything having to do with ModSecurity. I assume my host doesn’t have it installed.

I wanted to share what I found that makes the most sense. Some talk of editing the ModSecurity on the host, or having the host do it. One of them talks about if there is a call to a file that has the word ‘cookie’ in it then it triggers. Both my plugin and the other you mention have the same jquery.cookie.js filename included. I am going to change this in the next update to not have cookie in the file name but not sure how to test it yet..

https://www.ads-software.com/support/topic/plugin-triggers-mod_security-xss-rule

If you wanted to offer a begger a hand it would be two file edits to test if this is in fact the case. my problem, being the begger, is that I don’t have access to ModSecurity to tell us yay or nay. But, you do have access to my plugin files on your server I assume?

In the main plugin file called rss-llama.php, the following code:

wp_enqueue_script( "rss_llama_cookie", $this->rss_llama_url . "js/jquery.cookie.js", array("jquery"), "1.4.1", false );

would need to change to this: basically just the filename.

wp_enqueue_script( "rss_llama_cookie", $this->rss_llama_url . "js/rss-llama-wafer.js", array("jquery"), "1.4.1", false );

and then the file named jquery.cookie.js located in the /js folder would need to be renamed to rss-llama-wafer.js, so it matches the file call. Then, a deactive/reactive the plugin to see. that would be amazing if that is all it was.

But then, it also sounds like it is something that the WordPress and ModSecurity developters still need to work out with their error definitions, but would be nice to find out exactly what it is that triggers mine if not others. I hate to think I am doing something wrong here.

https://www.ads-software.com/support/topic/mod_security-for-wordpress
https://stackoverflow.com/questions/21483100/mod-security2-rules-for-wordpress