Wedge

There's no good way around that. Either you have to store both in the members table, or you have to store them both in the main thoughts table and query for them appropriately. Or one of each.

I know exactly what you mean :/

Well, I'm thinking we may have to do a join on the display page... I don't like the idea, but... Well, I don't know. I'd like more opinions.

That plugin feature is a bitch eh?

Technically, it's in loadMemberData where the join is. Hmm, lMD needs more branches than just minimal, normal, profile. Didn't we already talk about that before? :/

The plugin management itself is pretty straightforward. It's all the crap that goes with it, like dealing with file permissions[1] and figuring out how the update process should work.

1.	Seriously, while I understand the principles and so on of the way Linux/Unix file permissions are done, the whole lot of having to use FTP to elevate permissions on most systems instead of allowing the PHP process to run as the right user is just so mindnumbingly broken...

id_thought and thought can be in it, because it's only going to be used in the member's sidebar.

Things like smiley_set or id_theme/skin could also be in it (although the latter would prevent easily giving stats in the Change Skin page.)

Maybe timezone and language stuff, too. (It's used in a user's profile, though. But we could have some kind of function that gets the serialized array and extracts some data from it. As long as it's not used for more than *two* users at a time (the viewer and the viewee), it's probably safe.)

message_labels maybe... But it's a text field so it could end up eating the new data field's space. We could make the data field a LONGTEXT but it could end up wasting a lot of time unserializing data that's never used (outside the PM area.)

instant_messages and unread_messages are good candidates, too.

Well... What do you think? I for one would sure enjoy seeing a stripped down member table!
And TE's importer can easily deal with serializing imported fields.

Oh, while looking at the member table, I found a couple of definitions ending with default 0 instead of default '0'... I turned them to '0' but I've always wondered the point of using a string when an integer is perfectly fine... Maybe it was for compatibility with SQLite or PGSQL or something...? Maybe we should just go ahead and use integers....

Yes we did. And like with so many conversations, I guess nobody thought of adding this to their to-do list...

I completely agree with your view on FTP, but there's really nothing we can do.
I'd tend to say, "to hell with people who use strange filesystems", but the more we say that kind of thing, the less users we'll have...

Quote

id_thought and thought can be in it, because it's only going to be used in the member's sidebar.

Works for me.

Timezone doesn't bother me, unless we want to do some kind of display of user timezones. Language, however, has other consequences, like when sending email templates, it actually tries to fetch the right one for the language of the user the email is going to.

Not they're not. If you send someone a PM, do you really want to have to query their member rows, unserialize each one, increment, then update each row? If you send 10 people a PM, that's 11 queries. Now imagine sending a newsletter to each member via PM. As opposed to a single query that updates all of those things at once (which means only one table lock)

The dump is from either mysqldump or phpMyAdmin (not sure which) which escapes everything, anything that's without quotes is one added manually somewhere.

On top of that we were talking about using wesqlQuery with it too, which is probably why no-one did it, because it's hellishly complicated (and important to get right)

It depends on your definition of strange. From my point of view, the majority of filesystems are strange :P I did consider avoiding the whole upload process entirely and forcing users to use FTP but that's not very nice, now, is it?

Looking at some of your code in updateMemberData...

I take it you agree that a data field is a good idea then

I didn't know that instant_messages was calculated when sending a PM. I thought it was done when going to your PM area or something... So, scrapped.
unread_messages is probably in a similar situation.

Clearly, though, I'll be doing the data field because it's a good opportunity for plugins to store profile-specific data without having to add their own database fields (or custom fields).

I always wondered about that but didn't want to break it.

Ah, yes, that was it... I remember now how I was frustrated having to cancel my upcoming commit about that...

We could also simply say -- if your upload process doesn't work, use FTP and don't bother us with that! Just outputting a nice error message explaining what happened is okay to me...

Quote

Looking at some of your code in updateMemberData...

That was one of mine? Egad, looks ugly. Smells more like something that was there before and that I changed.

I'm a fan of such things, and I'm going to be making use of such when I get to implementing the per-user sanctions (e.g. through warnings and having permissions removed etc.)

Let me put it another way. Right now, one of the things I came to regret in WedgeDesk was the way the number of tickets is cached and not stored in the profile of the user. The overhead, despite caching, for that is surprising - and it has other consequences too that I won't get into.[1]

1.	Suffice to say, SSI has fun with it, and the logic around cache purging when tickets are updated is ridiculous.

and I can update it when necessary regardless for users with a single UPDATE,

Which means for a fraction of users, they have a cushy ride and everyone else is told to hit the highway. To be honest, I don't feel that's particularly acceptable, it's basically saying "I couldn't be bothered to make this work well for you." in my head.

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.....?

There's overhead whatever you do, the only way not to have overhead is to not do anything to the menu in the first place.[1]

1.	The only winning move is not to play.

Yup, and that's cool - provided that you are only updating one member at a time. The data field makes that a requirement, not a contextual thing. (You can update multiple rows to SET column = column + 1 in a single query, but you can't update multiple rows based on multiple criteria)

Pretty much all crap shared hosting (which to be fair, is almost all of it) runs the web server as www-data or nobody or apache, which means it's not writable.

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.

Even if it's running as www-data etc, I believe there are some ways to configure the server to make it work...

Quote

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.

Yeah, that one's pretty mindblowing to understand.

I will look at that, I never knew what the field did anyway.

It's created in one place, it's only used in one place, I'm not seeing what the problem is?

Yes... making files writable by default. Making an area of your space, that's going to be executable by live request, open to be modified by anyone else on the server.

You probably missed the PS I added after my post

The list? It's probably a good example of how a good idea (gathering similar data saving into a single array for easier maintenance) gets blown out of proportion and becomes totally unmaintainable because of silly validation functions etc. It's documentation in the comments is even more confusing. As if it was all written to be maintained only by its original writer...

Hmm alright...

Okay, going to bed early tonight. I'm tired... I think I've never spent so much time changelogging a feature. I must have re-re-re-reviewed the entire file list about 10 times in a few days...