Forum Replies Created

Viewing 15 replies - 1 through 15 (of 38 total)
  • Yeah, this looks like a server side bug in the code that generates the stats graph. The link in each bar int he graph is incorrect.

    Thread Starter MegaZone

    (@megazone)

    Frederick,

    I’d be happy to send you my current configuration for both W3 Total Cache and WPTouch. But even with that configuration there is still the issue of the browser caching causing the ‘sticking’ on mobile clients when toggling between the mobile and desktop themes in WPTouch. Adding some kind of query string to the URL seems to help, as in my proof of concept.

    Thread Starter MegaZone

    (@megazone)

    Tropa – Sorry, I’m still using the free version so the function may be different in the Pro version.

    I’ve actually upgraded WPTouch and I haven’t reapplied my hacks to the update yet. I just haven’t had time to work on it and I’m willing to live with the issue for now.

    Thread Starter MegaZone

    (@megazone)

    Huyz – I don’t know that you’re missing anything, but not everyone has the same needs. Personally I think AddToAny is just too much for my needs, it has a lot of bells & whistles that I have no interest in. ShareDaddy is ‘primitive’ compared to some other options, but that’s not a bad thing. I used to use Sociable, but I ended up deciding even that was more than I needed. I ended up deciding simpler was better, and the services included in ShareDaddy were all I really wanted/needed. I used to allow a lot more through Sociable – but they never got used, people only used the ‘big’ services to share – Facebook, Twitter, and Digg mainly. So why clutter things up with all of the other links?

    That’s one of the great things about WordPress and the plugins – you can customize it to your own needs and wants. What works for one site may not work for another. Different sites, different audiences, and different intentions. AddToAny is a great plugin, but not everyone is going to want or need the extra features.

    Thread Starter MegaZone

    (@megazone)

    I’m currently using the UA group that I posed above, and the conflict with WPTouch seems to be Browser Caching. I haven’t had any time to do more hacking since what I posted above, just been a busy week (business trip and then my folks were visiting). I did the hacks on WPTouch, but if there is a way to do URL re-writing in W3TC to force browsers to reload the pages when different themes are used (mobile vs. normal), or another way to solve the caching problem, that’d be great.

    For now I decided having mobile users sometimes get ‘stuck’ on one version of the page is the lesser of two evils, so I’ve turned on browser caching and I still have my quick & dirty WPT hack in place.

    Thread Starter MegaZone

    (@megazone)

    Karen – If you use P0l0’s patch it works, I’m using it on my site (GizmoLovers.com). (Which is in the middle of an overhaul pending a relaunch, so forgive the overall look, I’m not done. ?? )

    Thread Starter MegaZone

    (@megazone)

    OK, I whipped something up *very* quickly as a proof-of-concept. It is quick & dirty. A small modification to wptouch.php in the bnc_filter_iphone function:

    if ( isset( $_GET['wptouch_redirect'] ) ) {
                                    $protocol = ($_SERVER['HTTPS'] == 'on') ? 'http\
    s://' : 'https://';
                                    $redirect_location = $protocol . $_SERVER['SERV\
    ER_NAME'] . $_GET['wptouch_redirect'];
                            }
    /* START NEW CODE */
                            if (strstr($redirect_location, "wptview")) {
                              $redirect_location = str_replace("&wptview=normal", "\
    ", $redirect_location);
                              $redirect_location = str_replace("?wptview=normal", "\
    ", $redirect_location);
                              $redirect_location = str_replace("&wptview=mobile", "\
    ", $redirect_location);
                              $redirect_location = str_replace("?wptview=mobile", "\
    ", $redirect_location);
                            }
                            if ($_GET['wptouch_view'] == 'normal') {
                              if (strstr($redirect_location, "?")) {
                                $redirect_location .= "&wptview=normal";
                              } else {
                                $redirect_location .= "?wptview=normal";
                              }
                            }
                            if ($_GET['wptouch_view'] == 'mobile') {
                              if (strstr($redirect_location, "?")) {
                                $redirect_location .= "&wptview=mobile";
                              } else {
                                $redirect_location .= "?wptview=mobile";
                              }
                            }
    /* END NEW CODE */
                            header( 'Location: ' . $redirect_location );
                            die;

    What it does is probably fairly obvious – it sticks a query string on the redirect when changing modes, with minimal checks for an existing query string. (It doesn’t check for a fragment anchor, like I said, quick & dirty.) For simplicity’s sake before setting the query value I strip out any existing ones, the most direct approach.

    As a proof-of-concept, this works. I can turn on all the browser caching bells & whistles – expires header, cache control, eTag, etc. – and toggle back and forth between themes without getting ‘stuck’.

    There are obvious flaws – it is only concerned with changing that one page and the query strings are only on that first reload. When you first load the page, say it is mobile, it’ll be the bare URL. Then you toggle to normal, it reloads with ?wptview=normal in the query string and looks fine. Then you follow a link to another page, that page will load with no query string and in normal mode. Now follow a link back to the first page, which will load with the bare URL – and you’ll see the mobile version. Why? Because that’s what the browser cached on that very first load.

    A possible solution to this would be to have WPTouch tag a query string on *every* link as the pages are served. Or at least when serving pages in the non-default mode. (If you default to ‘mobile’ then only add query strings when in ‘normal’ mode, and vice-versa.) Then bare URLs are default and query tagged URLs are the alternate.

    If not in the free version, perhaps in WPTouch Pro? Having WPTouch working fulling with caching would be a nice feature. I did this mainly to make sure my theory worked in practice. I’m not sure I’ll have time soon to try to make extensive changes to WPTouch Pro. Frankly I’d rather just pay for a version with this working than do the work. ??

    Thread Starter MegaZone

    (@megazone)

    P0l0 – Thanks for this. But you had some errors in the main code, maybe introduced by the editor, that I cleaned up. Here’s the diff:

    1c1
    < < ?php
    ---
    > <?php
    149c149
    <         < ?php
    ---
    >         <?php
    158c158
    < < ?php
    ---
    > <?php
    195c195
    <     return '<g:plusone size="' . $this->_size . '" count="' . $this->_count . '"></g:plusone>';
    ---
    >     return '<g:plusone size="' . $this->_size . '" count="' . $this->_count . '" href="' . get_permalink() . '"></g:plusone>';
    209,211c209,211
    <       < ?php foreach ($this->_optionsSize as $value=>$name): ?>
    <       <option value="<?php echo $value; ?>" <="" ?php="" if="" ($this-="">_size == $value): ?> selected="selected"< ?php endif; ?>>< ?php _e($name, 'sharedaddy'); ?>
    <                                                                              < ?php endforeach; ?>
    ---
    >       <?php foreach ($this->_optionsSize as $value=>$name): ?>
    >       <option value="<?php echo $value; ?>" <?php if($this->_size == $value): ?> selected="selected"<?php endif; ?>><?php _e($name, 'sharedaddy'); ?>
    >                                                                              <?php endforeach; ?>
    218,220c218,220
    <             < ?php foreach ($this->_optionsLanguage as $value=>$name): ?>
    <           <option value="<?php echo $value; ?>" <="" ?php="" if="" ($this-="">_language == $value): ?> selected="selected"< ?php endif; ?>>< ?php _e($name, 'sharedaddy'); ?>
    <                                                                                < ?php endforeach; ?>
    ---
    >             <?php foreach ($this->_optionsLanguage as $value=>$name): ?>
    >           <option value="<?php echo $value; ?>" <?php if($this->_language == $value): ?> selected="selected"<?php endif; ?>><?php _e($name, 'sharedaddy'); ?>
    >                                                                                <?php endforeach; ?>
    226c226
    <           <input type="checkbox" <?php="" if="" ($this-="">_count == 'true') { echo ' checked="checked"'; } ?> name="count" /> Show Count
    ---
    >           <input type="checkbox" <?php if($this->_count == 'true') { echo ' checked="checked"'; } ?> name="count" /> Show Count
    230c230
    < < ?php
    ---
    > <?php
    269d268
    < </webcoder_at_binware_dot_org>

    You’ll notice I also made one change to insert the permalink so the +1 button works on index pages, etc. Otherwise every link on the page links to the page’s URL, which is the default.

    I recommend using the ‘Medium’ size button and adding this to sharing.css:
    .sharing li.share-googleplusone div { padding: 2px 0 0 0; }

    It helps align the +1 button with the rest of the row. Otherwise it is higher than the others and looks a little weird.

    Thanks again for doing the hard work of bringing this into ShareDaddy!

    Thread Starter MegaZone

    (@megazone)

    The lack of responses makes me think there isn’t a good existing resolution to this. Maybe I’ll find some time to dive into WPTouch and see if I can fix it.

    Thread Starter MegaZone

    (@megazone)

    Ah – I did that by using a text widget and copying the button code from Twitter.

    Thread Starter MegaZone

    (@megazone)

    Alex, what is the new twitter one? One of these? https://twitter.com/about/resources/tweetbutton

    Thread Starter MegaZone

    (@megazone)

    I checked out the Google +1 Plugin – one major issue, it inserts the button inside the last paragraph of the post instead of after it. So it ends up with a lot of whitespace after the button.

    It looks like a simple change:
    //add_filter (‘the_content’, ‘google1button’, 1);
    add_filter (‘the_content’, ‘google1button’);

    It would still be nice to have this built into ShareDaddy so everything would be in one group, on one line – it uses less space and looks better. But this is a nice interim solution.

    No problem. Glad it is working for you.

    OK, that error means you have two things defining a function named ‘Facebook’, and you can’t have the same function defined twice. Do you have another Facebook related plugin?

    I’d recommend disabling all of your other plugins, and trying just this one plugin. If the error goes away start activating your other plugins one by one, testing after each, until you find the one that conflicts.

    If it *doesn’t* work with just this plugin, something odd is going on. Try completely removing the plugin and reinstalling. If it still fails I suspect your server loads something by default which defines a function called ‘Facebook’.

    Thread Starter MegaZone

    (@megazone)

    Yeah, if I find some time I may dive into the WPTouch code to see if I can add a query string when in mobile and see if that does work. But I’d love for the Brave New Code guys who chime in here. I’m probably going to buy WPTouch Pro, but I’d like to get this working first to know it can be solved.

Viewing 15 replies - 1 through 15 (of 38 total)