Wedge

<ahhhhhhhhh, that movie...>Sure.

As for the data field... I'm looking into the members table and it's pretty hard finding something that isn't used in a regular query.
Some things like pm_prefs could be transferred, but they're set through a profile array that's pretty complicated and implies saving the variable to the members table itself... I'm not thrilled at the idea of tweaking that.

passwd_flood may be a candidate. I'd like to invite you to look into it... Try a global search for it. In some situations, it's retrieved from the database, but never used later. Look inside Reminder.php for instance. My guess is that it was planned to be used in validatePassword() (again, I'd suggest looking through all occurrences of validatepassword.) This may be an actual SMF bug...

secret_answer/question is a strong candidate too. It's used in a regular query, but it's always LIMIT 1 so it's worth doing an unserialize on it every time. Same problem as pm_prefs though, for saving.

Anything to justify having this new field, really... :lol:Even if it's running as www-data etc, I believe there are some ways to configure the server to make it work...

I use MANY hosts in the past. Only one had issues with modifying the filesystem through PHP, IIRC.

PS: feel free to fix any bugs you find in the thought system, now that it's committed. 'Modify' doesn't work anymore, I'll look into it tomorrow.

And here it is... The thought system.

rev 1145
(26 files, 47kb) (now we're talking!)

+ Added the Thought system from Noisen.com/Wedge.org into Wedge. Oh yes. Needs a lot of work though, as it only barely works for now. (install.sql, Ajax.php, Load.php, Profile-View.php, Subs-Members.php, index.template.php, Profile.template.php, index.language.php, Profile.language.php, script.js)

+ Added a 'data' field to the members table, that will hold a serialized array of variables that are only used by the current user. Added updateMyData() function which will cater for it. (install.php, install.sql, wedge_api.php, Load.php, Register.php, Subs-Members.php, Subs.php)

+ Added silent support for specific categories when populating the JumpTo object. I use that on Noisen, but I doubt it'll be of any use to anyone else... But never say never. (Ajax.php)

- Removed default_personal_text, which never made sense to me anyway. It probably had some use, for some people... Not for us. (install.sql, wedge_api.php, upgrade.sql, ManageMemberOptions.php, Subs-Members.php, Help.language.php, ManageSettings.language.php)

* personal_text is now parsed for BBCode. To preserve performance, this is being done when writing said text. We could possibly force reparsing when doing changes to the BBCode but right now it seems all right for me to do it this way. I have a feeling this is going to come back and bite my ass... (Ajax.php, Load.php)

* Reordering classes in the main script file, so that they follow each other. (script.js)

* $context['user'] should hold more references to $user_info, instead of copies. (Load.php)

* Minor optimizations/layout changes/bug fixes/HTML5 tags not worth documenting. (Class-DB.php, Subs.php, Display.template.php, PersonalMessage.template.php, Post.language.php)

@ Note: Pete, the keys in the thoughts table probably need some fine-tuning... Also, many things are not implemented yet: re-tweeting thoughts (if we ever do that), importing tweets (same, obviously), properly re-attributing master/parent IDs when deleting members or thoughts, etc. We should also consider whether to delete the dummy 'data'=>'' definitions and really, *all* dummy empty strings when registering a member or things like that... Fields all have a default setting, no point in setting them IMO!

The sitelist file in AeMe and Aeva Lite 7.2 is compatible with AeMe 2.x's. Just get the file and upload it, problem solved...

Technically it is... But so are many others.Oh, this strikes a chord.
Yes, there is a great amount of WP fanboyism in .net, but it's not particularly because of a secret organization or something.
The .net team is also biased towards: Jeffrey Zeldman (everything he says is The Future -- I have to admit the issue he supervised last year was excellent though, a great introduction to HTML5), jQuery, PHP, Ruby (they're trying to, at least...), and HTML5. But that's because a majority of web design agencies use these technologies in priority, and they simply discuss what people use -- because they need to sell. Web Design Magazine has the exact same scope, it talks mostly about WordPress, jQuery and PHP.
Heck, I'd say they're pretty transparent about it all. They published many a reader's letter about .net being biased, and they simply replied that they're trying to stay current. WP is what most web designers use to make websites, so they talk about it.
I'm more concerned about their biased towards ExpressionEngine. It's a paid-for CMS, not exactly cheap ($99 for the basic version), and half of their articles about CMSes discuss it. I don't see the point... I actually prefer seeing WP-related articles because at least it doesn't feel like they were paid to talk about it.

Possibly because most blogs don't require a lot of plugins...?

I... do not think it's for the best.
The only thing that will make a difference to me when it comes to avatars, is finally getting rid of any possibility of loading them through PHP. (Yikes...)

Ah, my bad! I just checked in SMF 2, and it's also there, so you have nothing to do with it ;)
I assumed it was your code because it's hook code, and I didn't remember writing it, and SMF has so little hook code that I just didn't even consider they could have written it.

I should have known better :lol:Good to know!
Any issues with the field being called 'data', btw...? That's what it is called in my local install. It's not very original and can be confusing, but at least it makes for a nice $user_info['data'] array.Well there's definitely some overhead too for the AeMe cache and it's stored in the profile table...Yeah, that's the thing with the data field: it's only for when you need to update one member at a time... Which is why the custom function I added for it (updateMyData(), can be renamed later) doesn't take a $members param -- it uses $user_info['id'] directly, at least for now.Do you have any stats, honestly.....? :-/

Oh, my... I didn't even take this into account. Well, at the time I wrote the feature, the sm.org server was very solid so I never experienced a downtime and didn't bother to check further.
I'm deeply sorry about this oversight.[1]

As for the task scheduler -- just like Pete said. Being backwards compatible means making choices. (Plus, I never really got the hang of the task scheduler.)

1.	Somehow, it feels like a DDOS attack sent by a guy that was post-banned long ago and wanted a late revenge.... :^^;: