WhitG

I’ll be damned, I think I fixed it. Turns out that this isn’t an uncommon problem with mobile iFrames. ??

I just had to create this class in my CSS:

.nivo-lightbox-wrap {
-webkit-overflow-scrolling: touch !important;
overflow: scroll !important;
}

There are still formatting issues that I need to resolve, but I’m relieved that these windows will scroll properly now.

That did it, thanks so much!

Note that this is with the “external script loading from the footer” implementation.

Thanks for the help, Tom! That seems to have helped with mobile, but unfortunately, it seems to have broken desktop menu usage:
https://breakoutbusinessbrands.com

Tapping on mobile screens now closes the menu, but clicking in desktop browsers will no longer open it.

Sorry, I should have included the URL where this appears:
https://breakoutbusinessbrands.com/

That’s a bit different to my situation, I was still trying to use v.2.x, which was supposed to work with the modal plugin. I never got any help, so I gave up and just put the form on its own dedicated page. Lousy support here, Ninja team.

Is this plugin still being supported? I feel that my implementation is correct and it’s going to create unpaid work for me if I have to find a totally different solution for this, I’d appreciate some feedback here, thanks.

And thanks for catching that error, but it’s unrelated – that script wasn’t present when I posted this.

Yes, I eventually had to get a developer to fix it, I wasn’t getting any response here and the site is about to go live. I don’t know what he did, but I can ask if anyone wants to know. All I know is that I had only performed cosmetic CSS changes that shouldn’t have affected the performance of the script.

Checking in on this, it’s been awhile, hoping it just got overlooked. Is no one else experiencing the close button failing?

I’m inclined to agree, though I could see a security rationale for not allowing uploads when the DB is malformed.

Ugh, I finally fixed it. Ultimately the problem seemed to be due to some sort of error in the SQL file. I never did quite hunt it down – I was able to copy over phpMyAdmin data from a known “good” SQL file and “sort of” got it to “sort of” work, but not really, and not in a way that would be acceptable for my clients.

Ultimately what finally fixed the problem – and I don’t imagine this will work for everyone in a similar situations (note here: try all of the other, much easier solutions first!) – was reverting back to the SQL file provided by the theme developer in the first place (that is, a modified version of that which included my own server/DB/user info). I was actually about to beg them for help when I decided to make sure that I was clear on the fact that their original SQL file carried the problem with it. But it turns out that it didn’t. I have no idea how I could have done anything SQL-related to cause this mess, but I have to assume now that I did.

In order to avoid replicating my own work, I was able to copy most of the revised page content/code into a text file with the “bad” SQL still in place, then copy that back into the respective WP pages after reverting back to the developer’s SQL. Tedious for sure, but my mini-nightmare appears to be over. Thanks again to everyone who tried to help out!

Funny you should mention that – that was where this whole thing started. I was trying to use a couple of plugins like that to get the WML to “see” images that were already uploaded, but both of them failed, I’m sure for the same reason that the upload issue is also happening, whatever the hell that is.

This should give you an idea of why I can’t afford to rebuild this thing from a fresh site:
https://digitaltoprintdesign.com

Well the plot thickens (or thins, depending on how you look at it). I backed up the database and then erased it, resetting WordPress so that it acted like a brand-new site. Lo and behold, the WML would then upload images no problem.

That suggests to me that a DB issue is at the root of this, but I’ll be damned if I know what to do about it. I compared the “fresh” DB with the real DB, and while I found and copied over a few minor differences, the vast majority of the differences were in the ‘options’ area, and they are simply too different to feasibly compare them. And when I replaced the fresh DB with the slightly revised old one, the problem came back. Boo. ??

I just wish some sort of log would give me a clue, but none of the logs I’ve been able to find make any mention of this error.

I am inclined to agree that it is a bug of some sort, or at least there’s a bug involved in the process doing what it’s doing, so I may go ahead and submit a report. In the meantime, though, I’m in trouble with this project – I can’t just rebuild the site from scratch, it involves a HUGE amount of effort and multiple developers.