bxwebber

Hi Maeve, thanks for your professional response. This is how I hoped my little review would work.
But I could’ve been a little more considerate (choosen words, stars…)

Luckily your plugin already harvested a good many 5 stars ??
So it’ll get there.

Digging into the code is not something most ordinary users would (or should need to) do. Plus: usability on tablets has become very important (if not to say decisive) these days.

I wanted to bring this flaw up for whoever it may concern… Isn’t that what reviews are for? I for one lost so many hours on plugins that proofed to have limited usability or were simply too complex to customize.

Is a fantastic plugin that only works in (let’s say) Windows still a fantastic plugin? Of course not. Likewise a great plugin that doesn’t cut it on tablets is not that great. Deal with it.

I already said sorry, in case you hadn’t noticed.

Thanks pupunzi!
I’ve taken out that piece of the script and that works for now.
I’ll keep a copy of the script and make a note of this so that I won’t forget when updating.

Maybe an idea for a future update to make this an option?

Thanks again. Good plugin.

Okay, now I understand from the reviews that the plugin hasn’t been updated for quite a while and doesn’t work on mobile devices.

A pity.

Hi!

Maybe this can help (it worked for me):
The original classes can be found in the plugin’s stylesheet, which sits in the contact-form-7 plugin folder > includes > css > styles.css . Of course it’s best to copy the ones you need into your child theme’s stylesheet and change the values.

My example (in which I changed the border- and background-colors):

div.wpcf7-mail-sent-ok { border: 2px solid #87cefa !important;background-color:lightskyblue; }
div.wpcf7-mail-sent-ng { border: 2px solid #87cefa !important;background-color:lightskyblue; }
div.wpcf7-spam-blocked { background-color:#ffa500; }
div.wpcf7-validation-errors { border:0;background-color:#f7e700; }

The !important statement seems necessary to make it effective.

Test it actually in IE8, I suppose.
I just viewed your site in actual IE8 (and IE7 compatibility mode) and the message does NOT show up…

Maybe you should check the plugin’s settings again.

Just happened to see your post. It so happens that yesterday I had the same issue. I corrected this with some extra CSS styling, like so:

.adv_browser_check { border: 0px solid #cc0000 !important;padding:20px;width:600px !important;}
ul.adv_browser_check_icons { white-space:nowrap;line-height:1; }
ul.adv_browser_check_icons li { margin-top:10px;margin-right:10px; margin-left:10px;width:60px;height:100px;white-space:normal;display:inline-block; }
.ie7 ul.adv_browser_check_icons li { display:inline; }
ul.adv_browser_check_icons li a { display:inline-block; color:slategray;}
ul.adv_browser_check_icons li a img {margin-bottom:8px;width:60px;hight:60px;display:block;}

Also made the browser icons somewhat smaller (they were huge) and skipped the red border. As you can see it even needed an extra rule for IE7.

Hopefully this works for you as well.

Yes, those IE issues…

You might consider writing your CSS styles for compliant modern browsers and then add some extra rules to that specifically for IE7 and IE8 (using .ie7 and .ie8 classes). Works very well, and is not that hard to do. Makes also sense because these days IE’s market share (especially 7 and 8) has dropped considerably.

The main reason I use the ABC plugin these days is to block IE7 users altogether…

What are you trying to achieve? I don’t understand the ‘compatibility mode’ – it sounds as if you’re trying to force the browser to run in a version mode that’s one of the blocked options in the plugin?

I’m using ABC in 2 sites and never had a problem running a number of other plugins at the same time, but sometimes plugin scripts can get in eachother’s way.

If you’ve activated the plugin, go to Settings in the dashboard main menu. There you’ll find the Advanced Browser Check settings.

Thanks, nice that you’re willing to dive into it!
But I think I’ve found a solution! The site is still local on my Mac, by the way. But this is what I did, basically putting the scripts in the parent theme instead of the child theme:

1. I left the div in the child theme’s header.php and css styling alone, but deleted the child theme’s functions.php and js file I made earlier.

2. Made a js folder in the PARENT theme and put the js file (called backbutts.js) in there with this script:

(function($){
$(document).scroll(function () {
    var x = $(this).scrollLeft();
    if (x > 100) {
        $('.topMenu').fadeIn(300);
    } else {
        $('.topMenu').fadeOut(300);
    }
});
})(jQuery);

3. in the PARENT theme’s functions.php I added just before the closing php tag this function (based on suggestions I found here ):

function my_init() {
	if (!is_admin()) {
		wp_enqueue_script('jquery');

		// load a JS file from my theme: js/theme.js
		wp_enqueue_script('my_script', get_bloginfo('template_url') . '/js/backbutts.js', array('jquery'), '1.0', true);
	}
}
add_action('init', 'my_init');

And this works like magic! Even when logged in.

Now I suspect that it could be something in the parent theme I’m using: BlankSlate, which is a stripped down ‘boiler plate theme’, ment to build things from scratch. Uptill now I did everything in a child theme set up, which usually works. Somewhere I read suggestions by the theme’s developers that eventually it’s best to create a new theme with it rather then sticking to a child theme. I’m beginning to see why ??

Maybe I’ll post a question about this on the theme’s support forum. For the moment, however, I’m happy.

Thanks anyway, for your follow up! Really nice.

One of the (many) combinations I tried was this:

1. In the child theme header.php goes a div that should appear if the script would work:
<div class="topMenu">SOME TEXT</div>

2. This div is styled in the child theme style.css:

.topMenu {
    display: none;
    position: fixed;
    top: 0;
    right: 0;
    width: 400px;
    height: 60px;
    background-color: red;
    z-index: 1;
}

3. I’ve put this script in a file called backbutts.js in the child theme’s js folder:

(function($){
$(document).scroll(function () {
    var x = $(this).scrollLeft();
    if (x > 100) {
        $('.topMenu').fadeIn(300);
    } else {
        $('.topMenu').fadeOut(300);
    }
});
})(jQuery);

4. and this in the child theme’s functions.php:

<?php
$path = get_stylesheet_directory_uri() .'/js/';
wp_enqueue_script('backbutts', $path.'backbutts.js', array('jquery'));

At first site this works without errors – until I log in to WordPress: then the cms and site go completely blank, so there are no error messages to check either, except for ‘Failed to load resource: the server responded with a status of 500 (Internal Server Error)’ in Safari.
Also WordPress automatically puts a copy of the parent theme’s functions.php in the child theme’s functions.php.

I suspect there’s something with wrong with the syntax (like the $ in functions.php?), bits missing or maybe registering the script the wrong way. I don’t have a clue, being a newbie in jQuery…

Thanks for your response!
I’ve tried the method you’re referring to, following the examples given here and here

In some cases it worked untill I logged in into WordPress: the site went white en WordPress put a copy of the original theme’s functions into the child theme’s functions.php…

I also tried what’s described here, putting a reference to the js script in the child theme’s header and the page template. Also unsuccesfull, the script didn’t load at all.

My problem is that I don’t know how to rewrite the piece of code I have (from which I know that it works in an ordinary non-Wordpress html page) and add the necessary new references. Most resources tell only part of the story.

Hopefully someone can tell me exactly what to do with this piece of code to make it work.

Thanks, Wingerspeed! But I’m afraid the update the update even makes things worse for me…
I gave it a try, this is what happened:

The reverse behaviour of the captions seems to be gone, but the captions still don’t return to their original (hidden) position after clicking the image, not untill the first mouse movement after returning to the gallery page with the browser’s back button. In iPad-simulator the captions of all clicked images are still visible after using the back button, unless you reload the page completely. I’ve tested this in a clean WordPress install without any other plugins or special themes running.

Worse: the update completely smashed the layout of my galleries…

So I’m sticking to the 2.3.3. version for the moment, but thanks anyway. You can see one of my galleries here:

Hi, thanks for responding, mbrsolution!

Might be a good idea to try the Jetpack forum.
Slim Jetpack is indeed 2 updates behind the byWP version.

Earlier on I’ve compared the latest Slim .js file with the one in the latest byWP version and there are differences in this bit of code. Part of my solution comes from that (copying the complete .js from Jetpack didn’t do the trick).

By the way, related to this issue I posted another question here .

Thanks again.