mrshaffly

Me as well, however the patch did not fix.

Same here. However, one caveat I’ll include is that I’ve had this happen on 3 sites. Disabling Wordfence does in fact bring back the dashboard. On two of the sites however, disabling Jetpack or Event Calendar would also bring the site back. Sites A and B had Jetpack in common. Sites A and C had Event Calendar in common. All three had Wordfence.

bank990999 is correct. There is something amiss with the first line of code. Nothing will display with that code in there. Removing it does display the echo.

This code is incorrect in some way:
if(($s2member_auto_eot_time = get_user_field('s2member_auto_eot_time')))

Glad I could help.

No, otherwise I wouldn’t see it on the interior pages. The home page is NOT protected to members only.

It is. And it’s only NOT displaying on the home page. I have a membership plugin that hides certain areas of the site when a user is not logged in. I do not see these or the tool bar on the home page, but if I navigate away I can see everything.

https://divawow.org/membersonly/

Actually, it’s only the home page that doesn’t show I’m logged in. If I navigate away the admin panel bar shows up, and so does the restricted areas in the menu items.

I’ve been going round and round with all parties on this subject for three days now, but think I’ve found a very workable solution.

First I opted to downgrade my WooCommerce back to to 2.0. I’m not sure this is necessary, but I was having other issues as well so did so.

Second, do NOT use the built in Force SSL option within WooCommerce. On your checkout, pay, and other secure pages, use s2Member’s force ssl custom field.

So far, I am able to run my store securely AND use the s2Member checkout functions well without error. Well, so far. Hope this helps others.

https://www.divawow.org/membersonly/

Is the site. I see these errors in Safari and Chrome. Firefox seems to be hiding them.

I disagree. It is very random. I had it placing p tags (sometimes opening ones or closing ones or both) or br’s in javascript code, sometimes, but not always, after an h2 tag, in the middle of a sentence, before or after legend or fieldset, but not always the same way…

It made no sense. Removing whitespace would sometimes, but not always change it from a closing p tag to just a br.

I wasn’t using TinyMCE either. Just the standard editor. It really got bad if I turned on all the features.

It would be hard to blame TinyMCE. I’ve had it working fine in Joomla for a very long time and have only noticed the issue in WP. It would be very good to find the root cause and get it taken care of.

I agree. It is not the visual editor. I’m getting varying results in a form with labels, fieldsets and legends.

https://www.jacksborochamber.com/membership-application/

If I take the whitespace out between the closing legend tag and the next table tag, the erronious closing p tag goes away and is replaced by a br.

<fieldset><legend>Company Name and Contact Information</legend></p>

Further down the page produces yet another anomoly

</table>
<p></fieldset><fieldset><legend>Membership Type</legend></p>

Moving the whitespace, or lack thereof, around produces different results around the same general areas. I would venture to guess that when 2.1 and 2.1.1 was last updated, the formatting.php file has been changed drastically, or, the built-in editor has.

This bug really needs to be moved up on the priority list of fixes.

Yes, that is correct. That bit of code comes from a file called classes.php. On or about line 510 to 514 is the code that tells the DB what to do with that LI and the a href link, and what classes to apply to the li.

I moved it from the li to the link without incident.

My next hurdle is finding where it begins formulating the parent code. IF I have a parent, I want the link of the parent to be given a special class (not the LI, but the A link). If it’s not a parent, it doesn’t need the class. But if it IS a parent, I want to give its link its own special class.

That kind of info is in a file called classes.php. Not a theme.

It doesn’t have anything to do with themes, and at this point I’m not using one. The page I referred to was a core file called classes.php, and it returns the LI code for Pages and Categories.

I’m very proficient in creating the CSS and HTML on the frontend theme, what I would like to find is the code in the core that creates the embedded list for subcategories.

WP allows you to make a category and then create a subcategory, right? Both of which have links. I found the code for those links, what I would like to find is the area in the core file, that creates that parent li so I can move the class off of the LI and onto the link and mark it as a trigger.

I found the basic area around line 510 of classes.php- a core file. If you have converted a PVII menu, then you probably know where it is, because all of PVII menu’s use the A tag, and not the LI to trigger the submenu.

I’m confused as to why you responded. Was it to just be degrading, pound your own chest or did you actually have a point?

If you don’t intend to help, then why respond? If you don’t understand what I’ve written, ask a question. But don’t tell me how great you are and then answer with points not even relevant to the problem.