KennyLL

Hasn’t this been an issue for quite a while now? See this thread for a fix someone came up with (I believe I tried it and it worked).

I just want to see if the author is going to (or has) implemented a fix like that, and even better, worked it into the settings so that the option could be enabled/disabled as desired.

We are also seeing the pop-up window background is transparent. While you can basically figure out where to add the info, and it will work after adding, it’s pretty challenging for new users.

We’re using VVQ 6.5.0 and WP 3.8.2.

Sorry. When I switch to second language (Spanish), there are no events listed. The page does display with the proper Spanish title, and as I’m using FullCalendar plugin the calendar view shows, but none of the events I translated are showing. I did try disabling FullCalendar, but same issue. And the widget shows no events either when in second language.

I’m using the following:
– WP 3.8.2
– EM 5.5.2
– EM WPML Compatibility plugin 0.3
– WPML Multilingual CMS 3.1.4
– WMPL String Translation 2.0.4
– WPML Translation Management 1.9.3

We have fully tested WPML and it appears to be properly translating posts, pages, Gravity Forms, media, slides, menus, etc.

I can also verify that the second solution (smaller one) in the final link does work here. It picks up the title of an image if there is one, or reverts to the Post title if the image title is left blank. The alt text shows up on the thumbnail, but is stripped out on the lightbox pop-up image.

Also want to watch this issue. I noticed it in 3.7.1, may have been OK in 3.6. Displays post title for every image, definitely not as elegant.

Can use captions, but then they show up under thumbs on page – also not elegant.

We ran into the same issue after working on fixing the problems with 3.4.5 and WP 3.3.1 (styles from editor-style.css not appearing). After getting the styles to show up at all, we then saw them randomly disappearing in Safari.

So we installed this plugin and it seems to be working so far. And we actually like being able to customize the formatting and styles options that our client will see. But just a couple questions:

– Is this going to work OK with future version of TinyMCE Advanced when updating?

– Any drawbacks seen after the few months of working with it?

– Any resources used by this plugin that wouldn’t be normally (we’re trying to keep our site a bit lighter so it’s not sluggish)?

Thanks!

Just a bit more after some testing.

It appears that we started getting the issue of styles working until we updated the page/post, then they disappeared (even after our hack mentioned above) when in Safari (FF fine). So it looks like we got the bug described here.

Just not sure if we got this bug after doing our ‘hack’ fix, after updating WP to 3.3.1, after updating TinyMCE Advanced to 3.4.5, or if we just had never noticed it before.

At any rate, we installed the TinyMCE Advanced Configuration plugin mentioned in the other thread (not happy about yet another plugin), and it did actually work – styles no longer disappear in Safari. So we now get a drop-down list of JUST the styles we want our client to see (none of the default WP ones). And we even make an entry to limit the formatting choices to only those we use as well. So this is actually better than it was before.

Just hoping the TinyMCE Advanced Configuration plugin doesn’t cause other issues, and that when this whole things gets completely fixed properly, we don’t have issues when updating now.

We’re testing upgrading our sites to WP 3.3.1 and just happened to notice this little bug. We don’t use styles for much, but there are a couple that are necessary.

We thought about going back to 3.2.7, but I think there were other features and bug-fixes added after that version that we would like to keep.

So we ended up trying a hack that someone mentioned in the Feb. 2 comment on the TinyMCE Advanced plugin homepage.

Basically, it looks like just using a bit of the old code from 3.2.7 to force the tadv-mce.css file to be loaded. Since I don’t believe that file is included in 3.4.5, we added it with just an ‘@import’ to point to our editor-style.css file in our Theme. If I knew PHP I would probably have been able to have the code point directly to the editor-style.css file and bypass the ‘tadv-mce.css’ file altogether, as I don’t think that’s been used for a few versions (correct?!?).

Hopefully this will suffice until a proper fix can be published. I’m pretty sure we don’t lose any of the features from 3.4.5, just get the style sheet loading again. I’m sure someone who knows PHP well could figure out a better and more permanent solution much quicker. I’d love to hear about it!

Hi David,
Well, what we did was purchase a domain specifically for all of our testing (i.e., webtest.com). Then every time we want to setup a new development site, we create a new cPanel account using a subdomain of this main primary domain (i.e., site101.webtest.com). With our hosting solution (we have a VPS with Host Gator), we can setup an unlimited number of subdomains.

So this works fine for development, as the main domain is setup and pointed to our hosting solution, so every new subdomain will just work like it should. Now we don’t have to worry about working around subdirectories that would not be there when the site goes live. Only the main domain will change.

When it’s time for our site to go live, we simply change the domain to what it’s supposed to be. We do this in WHM, not cPanel. So if you don’t have access to something like WHM, you may have to contact your hosting company to make the domain change. Make sure to change your site URLs in WordPress before you make the change, though, as you’ll be ‘locked out’ until the domain propagates.

BE AWARE, however, that when you change the domain you have to make some changes in the database because of the way WordPress likes to hardcode some paths for images & things. It’s a bit of a pain, but not sure of any way around it. Here’s a link that talks about it.

Hope this helps. There is a chunk of work to do when the site needs to go live, including some testing to make sure everything’s working properly, but not sure of any better solutions. We’ve created a bunch of sites now using this method.

Sorry, we figured it out.

We didn’t want to set it up in a subdirectory with a shared site, database, etc. We really wanted it to be in it’s own account on the root so things like email, FTP, databases, etc. could be setup properly for what they will ultimately be for each client. Makes a lot less effort when it’s time to launch.

So we found that we can add new cPanel accounts on our VPS as a subdomain instead of just a domain. So we have purchased one main domain for all testing and will just assign a subdomain of that for each new cPanel account/site we develop. While in development our sites will be at the root of this subdomain.

Then when we go live, we just change the cPanel domain and point the real domain over and it goes live. No transferring files, databases, etc. Less chance for errors.