Show Likes
This section allows you to view all posts where this member received or gave a like to.
1
Because he's worth two of our best men!
...No?
Well, apart from logging in with two different browsers, and even that is normally accounted for AFAIK, I don't know how it could happen...
...No?
Well, apart from logging in with two different browsers, and even that is normally accounted for AFAIK, I don't know how it could happen...
2
[Commit revision 45b22d9]
Author: Nao (Signed-off)
Date: Thu, 23 Jan 2014 15:45:31 +0100
Stats: 2 files changed; +141 (insertions), -0 (deletion)
Author: Nao (Signed-off)
Date: Thu, 23 Jan 2014 15:45:31 +0100
Stats: 2 files changed; +141 (insertions), -0 (deletion)
- Added a README for the plugin folder. It was screaming for one, really. (README.md)
- And a license file, too, just to be clear, and everythin'. (license.txt)
- Yeah, well, if all goes well, this commit should post itself automatically on the wedge.org website. We'll see.
- And it should be using some nifty little icons, instead of obnoxious +-*@! signs.
- This one means 'Deleted.'
- This one is 'Added.'
- This one is 'Modified.'
- This one is 'Fixed.'
- And, this one is a 'Comment'.
3
No feedback on the responsive YT embeds... Would this be a feature I shouldn't waste time implementing on other non-YT iframe-based embeds?
Also, in case you didn't notice, I (pretty much) finished writing an importer script that does this:
- connects to any github repository I care to feed it,
- retrieves the list of all recent commits (I think I still need to sort them, but whatever, usually I never push more than a couple of commits),
- gathers statistics about them individually, and then posts the results to a predetermined topic.
So, 'New Revs' will be connected from now on to the Wedge/wedge repo, while 'Language Revs' will be connected to the Wedge/languages repo. I will soon add Wedge/plugins to the 'Plugin Revs' topic, obviously. Any other repo that you think should be getting one of these special topics..?
Seriously, I'm pretty excited by this, because it needs I'll NEVER need to post to these topics again. Meaning I won't have to gather statistics myself. And less work means a happier Nao. And a happier Nao means more 'real' work done.
Also, in case you didn't notice, I (pretty much) finished writing an importer script that does this:
- connects to any github repository I care to feed it,
- retrieves the list of all recent commits (I think I still need to sort them, but whatever, usually I never push more than a couple of commits),
- gathers statistics about them individually, and then posts the results to a predetermined topic.
So, 'New Revs' will be connected from now on to the Wedge/wedge repo, while 'Language Revs' will be connected to the Wedge/languages repo. I will soon add Wedge/plugins to the 'Plugin Revs' topic, obviously. Any other repo that you think should be getting one of these special topics..?
Seriously, I'm pretty excited by this, because it needs I'll NEVER need to post to these topics again. Meaning I won't have to gather statistics myself. And less work means a happier Nao. And a happier Nao means more 'real' work done.
4
And here it is. I wanted to postpone it even more... But you don't deserve it. If anything goes wrong, I'll deserve it. In the meantime, please enjoy this; some of you have been waiting over three years for this moment.
https://github.com/Wedge/wedge
Read the README for instructions.
I will attempt to release a public alpha once I get some feedback confirming that everything's working all right.
https://github.com/Wedge/plugins
This is the official plugin repository. Most of these were written by Pete, John and Shitiz. The current license for them is the Wedge license; eventually, though, my goal is to make it clear which plugins are under more permissive licenses. Perhaps I'll even be able to make them all MIT, or something. If you write a plugin and don't want to share it under the MIT license, you can always push it elsewhere.
https://github.com/Wedge/languages
This one isn't a new repo, I introduced it recently on this blog, but what's new is that all of its files are now governed by the MIT license.
Lastly, if you're planning to make the switch to Wedge from an active SMF forum, please remember this:
https://github.com/Wedge/wedge
Read the README for instructions.
I will attempt to release a public alpha once I get some feedback confirming that everything's working all right.
https://github.com/Wedge/plugins
This is the official plugin repository. Most of these were written by Pete, John and Shitiz. The current license for them is the Wedge license; eventually, though, my goal is to make it clear which plugins are under more permissive licenses. Perhaps I'll even be able to make them all MIT, or something. If you write a plugin and don't want to share it under the MIT license, you can always push it elsewhere.
https://github.com/Wedge/languages
This one isn't a new repo, I introduced it recently on this blog, but what's new is that all of its files are now governed by the MIT license.
Lastly, if you're planning to make the switch to Wedge from an active SMF forum, please remember this:
- There is currently no 'proper' importer available. Pandos confirmed to me that the official importer is broken, so I'll look into it ASAP.
- Said official importer will be pushed to the Wedge/tools repo (or its own repo) when available. I'm planning to have it around by next weekend at the latest.
- If Thorsten looks into it before I do (I know he loves this kind of thing), then he may fix the importer before I do. See? A programmer's logic is no more complex than yours.
- It's still an alpha, even three years in. Meaning nothing is set in stone, and if a change I make breaks your forum, you can't complain to me. And if it makes it better, then you can't complain either. That was the whole point, after all.
5
This will be the default setup to make cherokee work with PrettyURLs in wedge.
Step one:
Go to cherokee admin and select the desired server.
Step two:
Change Handler of default from List&Send to redirect.
Step three:
Switch to Handler and choose Redirection as the desired handler.
Click on "Add new RegEx".
Choose "Internal" and type as Regular Expression:
Code: [Select] Type as Substitution:
Code: [Select]
Step four:
Click on Behavior + and add a behavior rule:
File Exists
Switch to Handler and make List & Send as default handler for this rule.
Move this new rule directly over Default.
Step five:
Click "SAVE" and restart cherokee.
Please make sure that PHP is always on top and it's status is "NON FINAL"
Step one:
Go to cherokee admin and select the desired server.
Step two:
Change Handler of default from List&Send to redirect.
Step three:
Switch to Handler and choose Redirection as the desired handler.
Click on "Add new RegEx".
Choose "Internal" and type as Regular Expression:
^/(.+)/index.php
Step four:
Click on Behavior + and add a behavior rule:
File Exists
Switch to Handler and make List & Send as default handler for this rule.
Move this new rule directly over Default.
Step five:
Click "SAVE" and restart cherokee.
Please make sure that PHP is always on top and it's status is "NON FINAL"
6
We're all happy for you
7
The more drastic solution I've proposed is the one that obliterates all tracking of any kind for non-logged-in users. You lose the ability to see how many guests there are and what they're doing, but you gain a massive performance boost and instant compliance. You also get some SEO benefits to not having to munge the session ID around.
That aside, it would be trivially possible to be absolutely compliant with the rules with almost no work by having the session ID pushed to the URL but that does raise issues for SEO. And you can imagine how many people won't like the idea of not knowing how many 'guests' there are, which means there's a debate on how to judge how active a forum is.
But it would absolutely solve all the problems by then making cookies required only to be logged in, and if you don't agree with that, you don't get to be logged in, simple as.
What I am seeing, though, is sites simply refusing access without cookies and being done with it, such as Games Workshop's site was doing last night when I looked, which is entirely legitimate as I understand it - but it spells doom for search engines.
That aside, it would be trivially possible to be absolutely compliant with the rules with almost no work by having the session ID pushed to the URL but that does raise issues for SEO. And you can imagine how many people won't like the idea of not knowing how many 'guests' there are, which means there's a debate on how to judge how active a forum is.
But it would absolutely solve all the problems by then making cookies required only to be logged in, and if you don't agree with that, you don't get to be logged in, simple as.
What I am seeing, though, is sites simply refusing access without cookies and being done with it, such as Games Workshop's site was doing last night when I looked, which is entirely legitimate as I understand it - but it spells doom for search engines.
8
OK, so I was contemplating how an arcade plugin might work, and in particular adding new games to one - as plugins themselves that depend on the main arcade.
And here's the weird thing, it occurs to me that we could do something truly neat.
As you know, the plugin manager works by the plugin-info.xml files, and the different XML indicates various things - there are XML tags for adding new bbcode, for adding scheduled tasks, and so on. What if a plugin could declare its own extra XML handlers?
So like the arcade plugin, it could declare a <arcade-game> block handler, so that arcade games could be bundled into plugins quickly and easily without having to do complex database changes or anything, just declare new items and let the arcade handler figure out what it wants to do with it.
In reality all we're really talking about is a hook in the enable/disable plugin routines that also passes the manifest SimpleXML object and plugins can register a hooked function for there. I don't think many would use it but it is certainly an interesting idea.
And here's the weird thing, it occurs to me that we could do something truly neat.
As you know, the plugin manager works by the plugin-info.xml files, and the different XML indicates various things - there are XML tags for adding new bbcode, for adding scheduled tasks, and so on. What if a plugin could declare its own extra XML handlers?
So like the arcade plugin, it could declare a <arcade-game> block handler, so that arcade games could be bundled into plugins quickly and easily without having to do complex database changes or anything, just declare new items and let the arcade handler figure out what it wants to do with it.
In reality all we're really talking about is a hook in the enable/disable plugin routines that also passes the manifest SimpleXML object and plugins can register a hooked function for there. I don't think many would use it but it is certainly an interesting idea.
9
Like button *was* visible to me.
Cannot put a day/time to thatstatement
Cannot put a day/time to that
10
This does also make me think that other actions should receive similar notifications, e.g. when a message has been approved from moderation. Thoughts?