rolevine

Never mind. I found out the answers by installing it, experimenting and scouring the documentation. Nice documentation by the way :).

@awol – This *might* be helpful to you. I have a situation where users submit stuff within each accordion section and the page refreshes. At this point I’m able to add a parameter to the URL. I add the title of the accordion section I want to re-open when the page refreshes. The following code takes parameter, finds the section’s parent anchor and clicks it. As an added bonus, it scrolls to the section.

const urlParams = new URLSearchParams(window.location.search);
var section = urlParams.get('section');
if (null != section) {
	var span = $(".ac_title_class:contains('" + section + "')");
	var anchor = span.closest("a[data-parent*=wpsm]");
	anchor.trigger('click');
	$([document.documentElement, document.body]).animate({
		scrollTop: $(anchor).offset().top
	}, 2000);
}

• This reply was modified 2 years, 11 months ago by rolevine. Reason: clicked Notify

@redswirl – hold your cursor over the exclamation mark.

@nuggetcreatives – Is this the error you’re seeing “Invalid address: (From):”. That’s what I’m seeing and the emails are still sent and received and there is most definitely an existing and valid email address.

Version 1.10.2

@sterndata – Not to be difficult, but offering to supply credentials is not a violation of the posted rules and I can’t imagine why it would be.

“Do not post or ask for login information, even test IDs and test passwords.”

I neither posted nor asked for. I offered.

@alanfuller – Thanks, I didn’t even need the plugin (though it’s good to know about) I just needed the inspiration to remember I had a code snippet that was including a jQuery script registration for a particular feature. Disabling that snippet fixed the issue.

– Rob

For what it’s worth, while hunting done a related problem, with another plugin, I found that a plugin “WP Custom Admin Interface” was causing my problem. I don’t know why, however, I guess I’ll stop using WP Custom Admin Interface.

@manigopal – I’ve had the same problem forever on one of my setups and I finally decided to attempt to debug the issue. Maybe @bungeshea can fill in the answer after I give the details.

Ultimately, the “false” that causes the “Sorry, you are not allowed to access this page.” to be thrown comes from line 2098 of /wp-admin/includes/plugin.php (WP version 5.5.2). The code is looking for the index “admin_page_edit-snippet” in the global $_registered_pages and not finding it.

On an environment where I am able to edit, the same piece of code is looking for “snippets_page_edit-snippet” (note that it’s different than “admin_page_edit-snippet”) in $_registered_pages and is successfully finding it. Hence, no error.

I’ll keep digging, however, I don’t know much about the area I’m digging into.

Regards,
Rob

• This reply was modified 4 years ago by rolevine. Reason: add WP version for file reference

@gevcen – on any one of my sites I can disable mod_sec, save a snippet successfully, then reenable mod_sec and fail with a 403 (not 404) every time. Though, as I’ve stated before, it’s because I have $_POST in my snippet.

@bungeshea – Thanks for the follow-up. The last point I want to clarify is that up until a few months/weeks ago, there was no issue with saving scripts with $_POST in them. So at some point, and I wish I could help identify that point, the issue started to happen where it previously didn’t.

I’m hoping that @bungeshea will update this after reading my posts #16 & #17. The issue that I’m seeing, while whitelist mod_sec masks the problem, it still seems to me that there is a CodeSnippets-specific issue happening.

@elenaocone @retunes @gevcen – I’m still curious if you see the same behavior in that there’s certain code that causes the error.

In addition to the testing in the previous post, I confirmed that creating a simple snippet with just “$_POST;” in it, fails on all my websites, including the ones where I thought I didn’t have the problem previously. As it turns out, it was because I wasn’t using $_POST in the snippet.

@bungeshea – Your post inspired me to do further testing and, at least in my case (error 403 while saving the snippet) I can see exactly what code is causing the issue. As to why, I’ll look to you for that answerd and whether it’s related to what you’re saying above.

If I create a completely empty snippet, it saves without error.
If I create a snippet with one simple line, e.g., “$x = 1;”, it saves w/o error.
If, however, I put “$_POST” anywhere in the snippet, such as a one-liner of “$_POST;”, I get the 403 error when saving. Same happens with $_GET and it happens even if I comment out the line, e.g., “//$_POST;”

@elenaocone @retunes @gevcen – I’m curious if you see the same behavior.

@elenaocone @retunes

I edited my .htaccess file to include:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

and while the problem did indeed “go away”, this seems both dangerous and the “sledgehammer” approach to the problem. Of course, I have nearly zero expertise in server security, so my concern is based solely on the fact that I don’t like the idea of removing security and that my host says that they “strongly suggest” that I don’t leave those lines in my .htaccess file.

Also, I looked at my sites that don’t have this problem and I don’t see the modsecurity rules touched in the htaccess files.

@retunes – I deactivated ALL plugins except Code Snippets and switched my theme to Twenty Nineteen and the issue still happens (403) for me.