Wedge

I still reckon the main reason it was asked for was a really a masked version of 'I want it now', something I got very very good at spotting when working with SimpleDesk, as most of the people who wanted to be beta testers didn't want to be beta testers, they just wanted it and didn't want to really go hunting for bugs.

I don't know whether FB holds the large image as well, but I know it does host at least a thumbnail image itself - or certainly did last I checked.

(I cannot presently post to the main New Revs thread, so putting it here)

(14 files, 20KB)

Revision: 1625
Author: arantor
Date: 23 June 2012 23:59:34
Message:
! Allow admins, admins+thread creator, logged in members, or everyone to see who voted in a poll, and make that controllable from the poll creation. Note that by design it should not be possible to change who can see this, as it might otherwise influence voting. (install.sql, Display.php, Poll.php, Display.template.php, Post.template.php, Poll.template.php, Language files: Help, index, Post)

! Added param for reqWin to prevent reqWin automatically grabbing a title. It's hackish, I'm sorry, but I couldn't think of a better way of doing it than this without altering every single case where reqWin was invoked. I didn't check how much larger it made script.js when compressed either. (script.js)

! Rearranged the likes display in posts to move the number to the right of the action itself, and to make that a link to the popup showing who liked a post. In order to do this some style juggling had to occur. If this can be improved, please please do so. (index.php, Like.php, Display.template.php, index.css, sections.css, Language files: index)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/Like.php
Modified : /trunk/Sources/Poll.php
Modified : /trunk/Themes/default/Display.template.php
Modified : /trunk/Themes/default/Poll.template.php
Modified : /trunk/Themes/default/Post.template.php
Modified : /trunk/Themes/default/languages/Help.english.php
Modified : /trunk/Themes/default/languages/Post.english.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/scripts/script.js
Modified : /trunk/Themes/default/skins/index.css
Modified : /trunk/Themes/default/skins/sections.css
Modified : /trunk/index.php
Modified : /trunk/other/install.sql

@ As discussed, this is not an 'I'm ba-aaaaack' commit. It's one that I did because it needed to be done and was annoying me that it had not been done yet. I consider it a WIP but I don't really know how to do some of it better. It may well be better just to revert bits of it and be done with it, but that's not really my call to me. Those who have source access, check it out and let me know.

@ This looks like a lot, but we're really talking about 6 hours work across three days. Nothing to even stress me out over.

Well, flash is disabled by default (though I'm not sure about Aeva type embedding, as to whether YouTube etc. put cookies in place), but with images, it strikes me that there is a method for dealing with it - there's already a request made for over-sized images, and it would not be difficult to check the response headers on that request as well and see if a cookie header was returned - and then perhaps warn the poster or even disallow it, but either way we can take some action.

Or perhaps like Facebook, taking a small version of the image as a local thumbnail (which is cookie-free) and linking to the external images with a warning about cookies.

Yes.Images have headers just like normal web pages, the cookie is an absolutely standard part of this (it's part of HTTP of sorts), so you can trivially set a cookie on requesting an image, just like you can to request a web page.

Yes, you are supposed to explain external ones - at least ones you know about. I saw your demonstration, but that's something that we'll have to deal with if and when it happens. I suspect the ICO would understand the fact that site operators cannot verify all content that they do not have control of.

The bottom line is responsibility: site owners who show signs of trying to act in line with the policy will be far less viciously hauled over the coals if a complaint is made.

Mind you, the way it's all implemented, most sites aren't being particularly explicit about cookies - XenForo for example has now complied with the law but falls a bit short on thoroughness IMHO, it doesn't even mention that the analytics cookies are from Google. And the cookies are set before the user has a chance to refuse them.

It isn't handled in a big switch case.

There's two parts to extending moderation filters.

Firstly, there's defining more types of rules, for example you could use that to declare a rule based on the number of likes a person has (since that's not currently in the system), you'd call moderation_rules to actually set up the actual processing of that rule. (You'd declare both its definition and if inside the admin panel, also go on to load the templates and language strings for it) - this is where the big switch comes in, but it's already extensible.

Secondly, there's the actual process of applying rules. This is currently not extensible in any fashion, but what would you want to do with a post in a moderation context, that isn't preventing/moderation/pin/unpin/lock/unlock, exactly?

If you did, for some random reason, want to set something up, add a new hook call in just before    // Any mistakes? in Post2.php.

Now all we gotta do is somehow make it possible to display these on the main thread view and we're golden ;)