Default avatar feature :)

[eurich]

I'm not 100% happy with the changes in Load.php related to $memberContext[$user]['avatar'] however it's to complicated to add it to the current checks (line 1116 ff)

Please review the texts carefully, my english is still horrible :P

Gravatars will follow soon :)

[norv]

Rebase has changed the commits hashes, that's why it's doing the trick on you... The quickest way is to just force, as above.
Nothing is lost or anything. Alternatively, you could play around with it, if you wish:

• when you are on the local default_avatar branch, git branch temp_avatar (creates temp_avatar branch as a full copy of the commits on default_avatar; it saves all new and old work this way)
• (make sure you're on default_avatar) and look at the log (git log), and choose some commit previous to the rebased commits too (i.e. from a few days ago)
• and reset the branch to it: git reset --hard commithash
• then, pull the commits from the github remote: git pull remotename default_avatar:default_avatar
  You should be back where you started the rebase, and your new commits are on branch temp_avatar.

You can, if you wish, take them from temp_avatar, to default_avatar, too:

• checkout temp_avatar (unless you use a client UI which already shows you all branches) to simply see the commit hashes in the log.
• checkout default_avatar, and git cherry-pick newcommitshashes

You can, if you wish, merge (not rebase) now, your master, to the local default_avatar. And push it back on github.

[eurich]

Thanks you for the details.. I'm still a git noob :P

[norv]

Cool and handy, thank you! :)

[eurich]

upgrade_files aren't planned for upgrading smf to elk? If so, I'll revert those commits / remove that code and let the changes only stay in the install files.. Are you fine with the other code for now?

Note: I have plans to add a new function detect_avatar_type() for the next pull request (gravatar_support) once this one gets merged. The current code for avatar detection is almost unreadable, at least for me :P

[emanuele45]

Yes, they are (sort of).
What Norv wanted to say (I think) is that it is enough to add the code to "upgrade_dia_1-0*.sql".
The "upgrade"/"conversion" process will follow the usual SMF way in order to maintain compatibility with any version of upgrade SMF supports (yabbse, 1.0, 1.1, 2.0).
So adding the setting to the last file is enough, no need to add it to any upgrade file.

[eurich]

mhh, from my understanding this is how it works in SMF:
upgrade_1-0.sql -> Upgrade an SMF 1.0.x to SMF 2.0.4 (always latest version)
upgrade_1-1.sql -> Upgrade an SMF 1.1.x to SMF 2.0.4
upgrade_2_0_dbtype.sql -> Upgrade an SMF 2 (any older 2.x version such as RC) to SMF 2.0.4

Which files in Elk will do the following task?

1. SMF 1.0 to Elk
2. SMF 1.1 to Elk
3. SMF 2.0 to Elk
4. Elk 1.0 to later Version of Elk (let's assume we have a 1.0 release and wannna update to Elk 1.1.)?

hahaha, now I'm completely confused..

[emanuele45]

Nope.
upgrade_1-0.sql -> from yabb to SMF 1.0
upgrade_1-1.sql -> from SMF 1.0.x to SMF 1.1
upgrade_2_0_dbtype.sql -> from SMF 1.1.x to SMF 2.0
upgrade_2-1_dbtype.sql -> from SMF 2.0.x to SMF 2.1
upgrade_dia_1-0_dbtype.sql -> from SMF 2.1.x to Elk 1.0

Note: upgrade_dia_1-0_dbtype.sql should be renamed to upgrade_elk_1-0_dbtype.sql or upgrade_elkarte_1-0_dbtype.sql

[eurich]

arg, need to update again.. lost the dia ugrades due to a --reset at some point :-/

[eurich]

ok, I think all should be in place now :)
(damn git, I hope I will get it sometimes ..)

[norv]

Thank you!