Nyhm
Forum Replies Created
-
Ah, I see. I didn’t realize that was the primary purpose of this behavior.
I’ll mark this topic as resolved, because the behavior is as you expect. I agree with keeping settings to a minimum for simplicity, yet I hope to see some built-in way of handling this case in future versions.
From a software feature design standpoint, I’d argue that my case is the standard common case, which aught to be supported by the default behavior, and the caching/CloudFlare situation is a special-case.
In any case, at this point, I think I have a working work-around, and I thank you for your support on this issue.
OK, I understand the explanation, and I see what the code is doing. However (back to my initial concern), why is it necessary/reasonable to change an HTTPS URL to HTTP.
It seems to me that pages can load some resources from HTTPS even though the page itself was requested/received under HTTP.
Your plugin makes sure that when on an HTTPS page, all URLs are HTTPS (to avoid mixed content warnings), but the other way around _decreases security_ (and breaks functionality, as my use case shows).
I would like to request either: (a) stop downgrading HTTPS to HTTP (unless you can explain the case when this is absolutely necessary), or (b) provide an option to disable this behavior.
Thanks for your support of this plugin! I’m very glad you’re willing to help your users.
I’m glad you figured it out! Could you please write a more detailed explanation, so I know when your plugin will alter my URLs?
I like what your plugin provides, and I want to keep using it, but I need to understand exactly how it behaves so I can make sure my site is fully compatible.
Thanks!
Thank you for your reply. In my case, the URL is hard-coded. When I load the page, then inspect the page source (as seen by the browser), the https://example.com/… is changed to http://example.com/…
My work-around seems to be OK, but please inform me if you can track down this behavior. I’d rather not have to rely on this work-around. Thanks!
Here’s the work-around that I’ve found for this particular case. The hook was not the answer. I changed the JS to hide the URL from your plugin, so it couldn’t strip the protocol spec:
var pkProto = (("https:" == document.location.protocol) ? "https" : "http"; var pkBaseURL = pkProto + "://example.com/piwik/";This fixes my failure case, but I still think your WP-HTTPS plugin should not be altering URLs that are in the page content like this. I understand that this is a core function of the plugin, but is there a good use case for changing HTTPS into HTTP?
Maybe consider an option to never “downgrade” HTTPS to HTTP in URLs.
… Just some thoughts/suggestions on how to further improve this otherwise useful plugin. Thanks for your efforts!
That’s a clever fix, thanks for following up.
I made a design decision not to have any slider on my site(s). Maybe I’ll look at vSlider again if I want one in the future.
I’ve switched to showing slides (screenshots) with jQuery ColorBox. See it in action at Island Forge.
dbonomo, I never heard anything else regarding this, either. (I’m actually not using vSlider anymore, but wanted to let you know that someone is listening.)
Forum: Plugins
In reply to: Site Crawl (not DB) based search plugin?No, sorry, I did not… and unfortunately there has been no other support from the community on my post.
I tried Sphider, but it took too much effort to integrate results (and didn’t really operate the way I wanted).
Ultimately, I just removed search from my site. Any further community insight welcome.
Forum: Plugins
In reply to: [DW ReWrite] DW ReWrite enhancement suggestionsI appreciate you taking the time to follow up on this.
I think your plugin provides much cleaner URLs than the defaults offered by WP.
(Although I’ve turned off your plugin for the moment, while diagnosing some unrelated redirect behavior, I hope to turn it back on soon.)
frankmontes, I’m still listening, and I still use this plugin, but I’ve had to make my own modifications.
Sorry, I do not know how to address the specific features you need. (Just wanted to let you and the community here know that people are still using this.)
Forum: Plugins
In reply to: [Secure Invites] [Plugin: Secure Invites] Email address link not URL encodedThat’s a good point, now that https is honored in the settings.
Forum: Plugins
In reply to: [Secure Invites] [Plugin: Secure Invites] Email address link not URL encodedThe problem might be because I’m using WordPress HTTPS plugin. Your email is sent explicitly to “http” but the plugin is then redirecting to the same URL but “https”. I notice that the @ symbol is stripped upon redirect (maybe WP being careful about URL encoding).
I can fix this by hacking your code to always use an HTTPS URL (then it works fine with the @), but that won’t survive an update.
Another solution is to URL encode the email address (becomes something like: test%40example.com), which seems to work fine and survives any WP redirect.
Thanks for looking into this. I hope it helps make your plugin more robust. This is a very compelling invite system.
Thanks!
Forum: Plugins
In reply to: [Secure Invites] [Plugin: Secure Invites] Plugin generates false 500 errorsThanks for your responsiveness to this. I think 403 will be much “friendlier.”
Thanks for responding to this issue… does this mean that the fade effect will be fixed in the next release?