Need to find documentation on the actual image insertion call, and i fear that would only be a tenth of the battle, it should be possible to keep the functionality without mixed content warnings tho.
ouch. if you set document_base_url to the address of the proxy server (which I'm guessing you're got running behind SSL) then maybe with convert_urls = false it could be persuaded to give an image url something like this? https://img-proxy.whyweprotest.net/http://www.site.com/img.gif and then the proxy just needs to fetch http://www.site.com/img.gif
Right except that people are dicks and because of that we need to hash and encode the image urls to avoid people getting "clever" and launching hundreds, thousands of requests through us: like https://img-proxy.whyweprotest.net/http://www.victimsite.com/img.gif?1 https://img-proxy.whyweprotest.net/http://www.victimsite.com/img.gif?2 https://img-proxy.whyweprotest.net/http://www.victimsite.com/img.gif?3 https://img-proxy.whyweprotest.net/http://www.victimsite.com/img.gif?4 etc ... The hashing uses a private key, that obviously needs to stay private, so we can't do clientside hashing for that part of the url. Writing a script that returns an encoded url without session / rate limiting and so forth would defeat the point of the hashing / encoding. This script would then be called from the clientside whenever an image is inserted into the editor. I still hope that king will find a easier / better solution, as this amount of work is .. quite a lot for rendering an image in a wysiwyg editor...
I see the problem. Yeah. what if the whole thing were to happen through Cloudflare? Then they'd put their own rate limiting stuff on top, I'm guessing... or could put a rate limiter on the proxy server. that way if anyone starts to fuck with it then it'll just drop offline... leading to denial of service for images on wwp, but preventing the proxy being used for anything worse... erm... I do see the problem here.
Unbelievable. Having nothing intelligent to add, I STILL wanted to share with how amazing and wonderful this thread makes me feel, so I tried to shoop a witty response, but when uploaded, they sent me this captcha. I'm stuck. halp http://i40.tinypic.com/35iohmd.jpg
Kinda gutted I didn't take on a dev role helping you guys now, this problem would have been one I'd have had fun with. Alas with the current project I'm on doesn't leave me much time to do anything at the moment. Looking forwards to SSL on here though.
I notice that in the dev environment pictures are accessible on one sub-domain but not on the other, like forums.whyweprotest.net Is this why we are going through the trouble of enabling ssl? To make like a "paid members only" club? for example this image displays fine when you directly type the url but the same images from that sub-domain won't embed on here on the normal forum. Let me embed more images so you can see what I mean: This is a picture of some guy holding his butt hole open real wide, I don't know what this has to do with goats but here you go. This next image is of some guy smiling really big, i think what's funny about it is that the guy is wearing a t-rex shirt. This picture here is of some japanese girl shooting a stream of watery poopy stuff out of her butt into her face in a bathtub. next we have a baby in an army helmet yelling "GET TO THE CHOPPA!" I think all of these pictures are pretty interesting but why can't we cross subdomain post them??? Is it my cookies that are different and other users can't see??? MORE QUESTIONS THAN ANSWERS :O
YOU SICK SICK BASTARD - THIS MIGHT BE LEGAL IN JAPAN OR GERMANY BUT NOT IN AMERICA!!!! smh Gonna request mods to ban you from enturb.whyweprotest.net - good luck getting out of a cookie lock!
site went down with a cloudflare error around 2:17, don't know how long it took to come back up, probably 30 minutes? happened at the same time last week too - just forgot to report it :/
I'm getting '502 Bad Gateway' errors from cloudflare intermittently (maybe one an hour). On reload it's fine. I'm in the UK.
Serious problem with initiating conversations this afternoon. I get the name field and the subject field, but no message field. Similar issue a Member had last week, trying to start a new thread. All the fields present except the message field. I've done all the usual trouble shooting - dumped history, caches, cookies, etc., re-started the browser, and the problem persists.
I'm not able to start any new conversations/PMs. It only shows the subject and "to" fields, but no "text" field. I am able reply to PMs/conversations received earlier than today, just not initiate any new dialogue. I've cleared out caches, etc. to no avail. I am aware of at least one other user who has experienced the same issue today. Thanks, in advance, for your consideration into this matter.
It's not a cloudflare problem. It IS a web browser problem, with Firefox 9.0, reported elsewhere. http://forums.whyweprotest.net/threads/support-question.97319/ You can do one of three things: use a different browser. Either a newer or older Firefox, or something different. turn off Javascript (temporarily) before you start a new PM, or create a new thread. Then turn it back on. wait..... for XenForo to release a new patch, and for WWP admins to update the server to use the new patch Sorry for the inconvenience.
Thank you for the advice, and the reminder. Been so busy these last few days, I had completely forgotten the prescription remedy for the ailment.
If you check the XF discussion forums, you'd see there are compatibility issues raised by those workarounds currently proposed. I see your "laziness" and raise "due diligence".
For all I know, sue might be working on such a patch this very minute. Sue's tendencies are to announce completions more than announce works in progress. Cloudflare is a work-in-progress but I know there are many other projects on the workbench. Site admins lazy? I don't think so.
Had a look now and you're right. http://xenforo.com/community/threads/firefox-9-beta-no-text-box-on-create-topic.23174/ The issue is with changes to the console object if given a var that does not exist. They list the fix as: Code: console.info('Title Element: %o', this.$title); to: Code: console.info('Title Element: %o', $title); But apparently that's not working for some people and it'll break other browsers. As a temp fix use this: Code: console.info('Title Element: %o', navigator.userAgent.search("Firefox/9.0") ? $title : this.$title); I don't have xf installed to test it on, but that will get around the other browsers issue atleast.
Anonymous posting currently disabled since it doesn't play nicely with the latest version of xenforo.
Turning off "Use the rich text editor to create and edit messages" in XenForo Preferences fixed this Firefox issue for me.
Things with FF 9.0.1 and an Intel Mac seem vastly improved. No need to disable JavaScript in the FF preferences and the interface for setting up a conversation is even more user-friendly!
Seems fixed now. Message body textarea renders (FF 9.0.1/win) , with or without the "use rich text editor" Pref set. Thanks, very much.