scienceofspock

Ok, now I need to do some work on the site, because it disabled the plugins FOR REAL, not just for me. FANTASTIC.

The option isn’t available in the plugins section, and the plugins are not listed under the “Enable Plugins” section of the troubleshooter. It’s like it’s just not even aware they are there, but it certainly disabled them for me.

Edit: to be clear, the option to enable them isn’t greyed-out, there is NO option to enable the remaining plugins at all. They are just disabled.

• This reply was modified 6 months, 1 week ago by scienceofspock.

Still experiencing this issue, still.

Still experiencing this issue.

The plugin name is “Leaflet Map” and has a version number of 2.23.3, and I clicked a link from the leaflet settings page to get here, so I’m REASONABLY sure it’s the right plugin. I did manage to solve my issue, though. I’m just trying to understand how this site is configured.

Sorry, I’m not really familiar with this plugin, but there are 6 “leaflet-” prefixed classnames on the map div, and it creates the map with a js call to L.map() which points to leaflet.js:5. It also has the leaflet plugin installed and active. Is that not evidence?

Thank you! Why in the hell did they add this “feature”?

So, I tried it out on another local site I have set up, with a different theme, different content, different plugins, etc. Completely different site, and I can’t get it to do anything there either. Clearly, I am doing something wrong, but I am following the setup instructions here: https://share-this-image.com/guide/installation/ and I can see nothing that I am doing wrong. So what is it? Why can’t I get this to work? What am I missing?

Solved, this was only happening on a page with another CF form on it. That page ALSO had some code that injected the “panel” class into all “caldera-grid” classed divs.

Someone has to know how to do this, right? I mean, custom fields are still accessible in Gutenberg, right?

That looks like exactly what I’m looking for, thanks!

This seems to be a theme issue and I have figured out a workaround.

Yeah, the issues are NOT related, just coincidental. But that table does not exist in my database. I have removed the plugin and reinstalled it, and the table still isn’t there, though I’m not sure if it’s created at install time or not.

It stems from the way some of our sites were initially set up. Some repos are actually used for multiple sites (but not using wp multisite, since that wasn’t around when these were built), with the only difference being the theme folder and database. Our setup allows us to work on those multisites locally by copying the wp-config.php to a new file that is basically <domain name>.wp-config.php and then inside wp-config.php we have code that loads the proper <domain name>.wp-config.php based on the domain of the site. so if I browse to a local wp site at the URL local.foo.com, wp-config.php will load local.foo.com.wp-config.php. If I browse to a different local wp site at local.bar.com, it will load local.bar.com.wp-config.php. Both those sites are the same physical directory and same repo. It’s kind of a weird setup, but it works for us.

I figured this out and it was a stupid, stupid issue. I have a custom wp-config.php setup that breaks out the individual sections into different files and then includes them from wp-config.php proper. My pathing was incomplete, so at the root of the site, it was actually loading all the parts of my wp-config, but from wp-admin, it couldn’t find the wp-config files because it was essentially looking in ‘./’ instead of going back to the document root, and because I tried to make sure the files exist BEFORE including them, it did not even try to include them because it couldn’t find them. So much for trying to overthink and prevent stupid error messages.