Andrew Miguelez

I have created a new theme from scratch. Added a style.css file with a theme name, an empty functions.php file, and an index.php file resembling the one I described in my last post.

The error still exists, even when I wait to install and activate the MMR plugin after activating my test theme.

I’m completely stumped. It’s not even the database, because the error isn’t occuring when switching to a default theme. Sheesh…

I have modified my index.php theme file to the following:

<?php
wp_head();
wp_footer();

functions.php file is renamed, all other plugins are deactivated. Error still exists.

If I remove wp_head() from index.php, the error is gone. But as I am no longer affecting either the head or foot of my theme with functions.php, I don’t know why this is happening.

I renamed functions.php and deactivated all other plugins, but the error persists. This has got to be some strange bug. I’m going to start messing with all theme files to see if I can simplify the page until the error disappears.

I’m not able to grant you access to local. If I can’t get it figured out, I’ll setup a staging site on a subdomain that you can get into.

I just verified that the issue was occurring on my local environment too so I could do some testing there. I installed the Twenty Sixteen theme and activated it. The issue was gone. And back again when I re-activated my custom theme. So this is definitely something related to my theme/JS files/enqueuing in functions.php.

Not really sure where to begin. Any advice?

The live site is: https://andrewmiguelez.com
I did not have any caching plugins at the time of my original post. I have now activated WP Super Cache. I want to give your plugin a chance, so I’m holding off on testing any others at this time.

PHP Minify has been updated with a fix to the Plugin Author’s submitted issue.
See here: https://github.com/matthiasmullie/minify/issues/133

I would suggest resolving this topic unless the OP maintains that their issue still exists.

[EDIT]
I just realized the plugin hasn’t been updated yet to the most recent version of PHP Minify (including this fix). After an update maybe we can resolve this… ??

• This reply was modified 8 years, 4 months ago by Andrew Miguelez.

“Broken” isn’t specific enough to know if the plugin actually did damage to your WordPress installation or database. So I will assume this is an issue with some of the CSS or JS minified files not allowing the theme to behave as intended. In that case, you simply need to deactivate the plugin and the site will resume as it was before activating.

Note: Before deleting the plugin entirely, I would utilize the plugin’s settings page to modify the way it behaves with your theme. Do some testing (basic trial and error) and see if you can’t get everything just right.

This definitely already exists by using the exclude textarea. However, is it possible to exclude with a wildcard? For example, could we exclude all files coming from the wp-include folder with an asterisk?

Otherwise I’d say the addition of an “exclude” link next to each affected file that, when clicked, automatically adds the file to the exclude area would be a nice UI/workflow improvement.

I can confirm that in WP 4.1.1, overwriting my simple_fields.php file with the latest from master, did remove the errors for me.

This is the version I used:
https://github.com/bonny/WordPress-Simple-Fields/commit/7cc4a8e924ec73d05f6c35bfd67bcafda3d79504

I’d like to also note that this issue has only shown up in 1 of 4 WP admins that I’m able to check at the moment. As it doesn’t break anything, I think you should push the update.

The project I needed this solution for is long finished and I forget how I went about handling it. But your answer is sufficient to resolve my topic. I hope this is a help to others searching for a way to do the same thing I was.

Thank you, @acts7.

The plugin currently does not show pages in the same order in tree view as WordPress does on the front-end. If I output the page list, it will display in alphabetical order unless any pages have had their order set. If I understand your proposed addition to the next update, you will match WP in how you display the order of pages in tree view.

However, what will you do about reordering pages? If I drag and drop a page in a branch of unordered pages (all page orders still set to ‘0’), will TPV still show that the page has been reordered as it does now? Technically, TPV is only applying an order number to the affected pages. Shouldn’t it apply an order number to everything in the branch so that the front-end matches the tree view?

I realize this is very confusing, but I was confused when I tried reordering pages today and noticed that the front-end wouldn’t match until I manually reordered each page at least once.

It’s a great plugin! Some parts of it are confusing though. I recently had to figure out the solution to this same problem. It’s fairly painless.

What’s going on:
Since each tab is just a WYSIWYG-ified Custom Field, when you remove the MultiEdit region, the Custom Field is left behind. As a safety measure, MultiEdit will never delete a field, so it shows the orphan fields as grayed out tabs.

How to fix:
Navigate to the page with outdated tabs in the admin. If the Custom Fields box isn’t already visible, click “Screen Options” in the top right of the page and turn Custom Fields on. Click “Show/Hide MultiEdit Fields” and then delete the outdated fields.

??