Forum Replies Created

Viewing 15 replies - 61 through 75 (of 224 total)
  • Thread Starter Alvaro Degives-Mas

    (@nv1962)

    So far so good, no more mixed content issue here! Awesome – thanks again, Donncha!

    http://wordpress.org/extend/plugins/wordpress-https/

    Install it, adjust setting to only set SSL on pages & posts you indicate per post (with a checkbox in a widget) and voilà – done.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    OK. Don’t laugh.

    I know what Subversion is, but eh, I’ve never used it. So I had to wait a few days until I had time to research it and find what I need to know and have running to pull those files (I stubbornly figured that’d be even faster than pulling all files with right-click save as…) so that’s why I’ve been mum.

    I apologize for being an udder coding n00b (then again you can ask me more about localization issues, fortunately)

    I just pulled the files; it’s now running, and so far, so good. I can’t thank you enough for being so fast with this!

    BTW: earlier this evening I ran into these guys here who offer a free 1-year but of course unvalidated simple SSL cert, i.e. for just one (sub)domain. You still would need a static IP to get it going but even their wildcard cert (I’m using SSL just for encryption / privacy purposes) looks darn cost-effective.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    It’s going to feel like Christmas all over again!

    Interesting that, cfisher, but Mr Ivan Malijkh jumps straight past Frederick Townes’ important reminder:

    CloudFlare is *not* a CDN, nor is it their intension to be.

    (My emphasis)

    After all, CloudFlare has a security focus. The approximate CDN functionality is a nice extra thrown in, arguably (perhaps) to offset the tiny extra time for originating IP lookups. But their focus is on internet hygiene, not performance optimization per se.

    Nonetheless… It’s still an interesting article, as it shows that picking the appropriate distributed content delivery method and provider does benefit from selecting one that is within geographic proximity. I.e. as Ivan Malijkh already notes, he has sites served from the Netherlands, and when the users (visitors) are also in the Netherlands, the obvious CDN choice would be in that same country, too. That explains why his setup with CloudFlare fared not so well; it’s not so much about CoudFlare’s service but the Netherlands not being in Kansas anymore, Toto.

    Again, Frederick Townes’ reminder is important to keep in mind (if you forgive me the department of redundancy department)

    Yeah it can get complicated very quickly! Just to be sure: don’t mix the use of self-hosted CDNs in WP Super Cache together with CloudFlare if you’re going with their generous Free service. Their paid Pro service can handle CDNs with more flexibility, but I suppose most will want to look into their Free service first. BTW: CloudFlare picks up static files (images, JS, CSS) automatically, to serve those from its farm, so that amply compensates the “lack” of self-hosted CDNs. Also: when minifying javascript and CSS files (either with a separate plugin or inside W3 Total Cache) be careful to not minify already minified files (if the JS or CSS code already looks like a solid block of text, it’s minified already – some plugin developers do that to speed up performance.) And finally, some JS simply doesn’t like being minified and/or concatenated. In my experience, it’s best to do things step by step: get the cache working first, then add minify, then work with CDNs to see if that works, too.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Good point, about double checking the PHP version. I’m positive about the version, though. Perhaps for others: when in doubt, create a blank text file and name it something like versiontest.php or something (it’s not a good idea to name it as often is done info.php as it tends to be forgotten out there and it does give a very detailed run-down of your PHP configuration) and then put the following in it:
    <?php phpinfo() ?>
    Save it, upload it, visit it and look at the PHP version.

    And then delete that file, you don’t want to hang a blueprint with a detailed map laying out your home, posted outside the front door, either.

    Yes, WordPress HTTPS indeed adds a checkbox to every page and post, allowing it to be “hard-set” for HTTPS access. However, in our case things get complicated really fast as we also use a poor man’s CDN (i.e. subdomains on our own shared hosting account) and for a proper HTTPS page display you need a specific SSL certificate for any domain over which you serve that page. As I said: poor man’s CDN, so a fairly expensive wildcard SSL cert (to cover all our subdomains) is out of our non-profit league, as of yet.

    +1 on WP SuperCache and CDN for shared hosting enviros.

    By the way, I think both WP Super Cache and W3 Total Cache are incredible and excellent, so I have no bias whatsoever against either – it’s just that presently, again: for shared hosting situations, WP Super Cache together with the self-hosted CDN option (make sure you also use extra subdomains in the “Additional CNAMES” field, like cdn1.example.com, cdn2.example.com, cdn3.example.com) is a solution that can stretch your traffic a long ways and is slightly easier to get and keep working.

    In addition to the earlier great suggestion to also use the WP Minify plugin (i.e. together with WP Super Cache) also look into the oft overlooked WP Widget Cache plugin: as the name suggests, it is very helpful if you have widgets in your sidebars, and you can activate and tweak caching duration on a per-widget basis, and best of all, it works like a charm with WP Super Cache.

    Finally, a tip which steps outside the realm of caching and instead looks at the volume of traffic itself, i.e. a wholly different approach: look into the (free) CloudFlare service. That is a reverse proxy type filter based bad bot blocking service, which essentially cleans up the traffic by eliminating most of the bad stuff. Oddly enough, that service works better with W3 Total Cache! If you go with the free service mode, the CDN issue becomes practically moot, as CloudFlare already does a lot of caching transparently for you. Again, that’s a different approach, but it may be just right for you.

    It’d be neat of WP Super Cache also supports CloudFlare, then again: it’s tried and tested to work very well with W3 Total Cache already.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Wow Ed, thanks for that thorough explanation! About the first issue: yes, we’re running PHP 5.2.14 so I don’t think it’s a version induced problem. Also, to be sure: the use of SSL is an issue that primarily relates to wp-admin access (including, of course, login and registration – to protect the innocent and clueless WiFi users alike).

    However, we’d like to also be able to select just a few more pages for “forced” SSL access (e.g. event reservations, contact form) which then, of course, would complicate things even more.

    Either way – I full well acknowledge that this “issue” is relevant to a very tiny group of users. Then again… I suppose it’s reasonable to surmise that that tiny group may well on average have mid-to-higher traffic levels (hence the interest in SSL and security in general, to begin with) which suggests they’re generally more prone to being strafed by bad bots. I.e. it might make it interesting as a test lab. However: I’ll also admit that I’m just trying to seem like a slightly more relevant tiny minority here! 😉

    Thanks again – I very much appreciate your hard work for making the WP reliant community a better, safer place.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Thanks for the quick reply! Well that makes sense then. I’ll do the unthinkable then and hack it into the WP core files.

    It’s probably better to check at the cF post as I’m (euphemism alert) not too sure they keep an eye on this forum.

    Yep, resolved for me too: I have WP3.0.4 running its wp-admin backend over SSL and WP-Piwik works like a charm! (In some cases, also having WordPress HTTPS installed helps to resolve the last odd mixed content bits)

    Are you using Piwik Analytics or WP Piwik*? The latter is updated for WP3.0.X and Piwik 1.1.1 support, and also addressed the entity encoding issues (and has been very recently updated for compatibility with the current Piwik 1.1 and its subsequent 1.1.1 bug fix release)

    *I’m almost certain you’re using Piwik Analytics as in the topic tag here you put Piwik Analytics, and the code you’re referencing isn’t found on line 97… So that’s why I suggest using WP-Piwik instead. Try it, if you don’t have it.

    Look under Settings and you see the WordPress HTTPS settings right there.

    No need to change that code anymore in Bad Behavior to make it work flawlessly with WP Super Cache: inside the WP Super Cache settings (in the new plugin tab) just activate the Bad Behavior plugin and you’re good to go.

Viewing 15 replies - 61 through 75 (of 224 total)