Question [Solved] Avatar Gallery Not Functioning Properly

I'm using Installed version: Kunena 1.5.9 | 2010-01-23 | 1869 [ Susurrate ]

My problem is that I can successfully upload avatars from the "Default Gallery" but I can't select an avatar from the very same gallery. The avatars appear and you can bullet one of them, but Confirming the selection does not register the selected avatar and not even the "NoPhoto" avatar is then available.

Curiously, some places say the gallery folder is /components/com_kunena/kunena.files.distribution/avatars/gallery, as does the Admin Forum Configuration screen. Yet, I've found that only the /media/kunena/attachments/legacy/avatars/gallery is processed.

Also, I'm developing on WAMP where I can't adjust permissions, but as I said, I can upload from that folder.

Hello,

You can try with K1.5.10 if this works better.

i found K1.5.10 avatars work perfectly you can even upload ur own as a user and it works with no errors

I see the bug fix list for 1.5.10 contains [#19902] Remove extra { which causing issues with avatar uploading.

I checked the table and that is indeed what is happening. An extraneous "{" is prepended to the avatar name and stored in the table.

However, I hesitate to reinstall/update Kunena. I've done so much customization I'm just afraid I'll break it.

Instead, I opted to fix the offending location for the avatar selection process,which appears to be around line 335 in components/com_kunena/template/default/plugin/myprofile/myprofile_avatar_upload.php as there is a double curly brace "{{" at the beginning of the assignment that needs to be corrected to a single open curly brace.

The same issue seems to also apply to around line 162 involving the delete process.

nikkie wrote:

However, I hesitate to reinstall/update Kunena. I've done so much customization I'm just afraid I'll break it.

This is one of the main reasons for developing K 1.6: because users make a lot of custom CSS changes, and hacks to the code to present the information in a specific, tailored way.

Although we're always happy to see users share their ideas, their hacks, everyone should remember that the changes you make today will be dead-weight that you'll have to carry with you into future versions.

K 1.5.10 fixes 30 known defects. 30 known defects! That's not a small number of fixes. K 1.5.10 is also unfinished - it, too, introduced a couple of unforeseen problems - and there is to be a K 1.5.11.

So, you see, there will be no support for K 1.5.9. Indeed, right now, there is no support for K 1.5.8. It will not be too long before there is no interest in K 1.5.x at all.

You have a choice. Stay where you are, with your customisations, and 30 known defects, or abandon the customising and keep the core functionality up-to-date. It's a choice between reliability and appearance, between what's fashionable to look at and what is functional, durable, and will withstand the wear-and-tear. I know what I would rather do, but I respect your decision.

wat sozzled said but with less woffle but seriously he right it well worth the time to customize again for the benefits of the 30 bug fixes

I agree. That's generally my philosophy. And that's what was so promising about the "so called" template overrides, when they are properly included. The idea was good but access to just the presentation HTML is not enough. The same segmentation should exist for data and logic, at least on some level. But that takes a lot of rewriting, and no one enjoys that. Anyway I'll eventually get around to interleaving the bug fixes.

The only real substantive change I made is something I think should be part of the system. Who can really say what is useful in terms of social networking and user profiles, other than to guess at what's useful by providing the most popular? But why provide these options as canned options?

A more flexible approach, and the one I've taken, is to allow a profile to store contact information as variable methods. There are a good 30 or 40 plausible contact methods out there in use, whether handles, http or e-mails. Additionally, why constrain a user to one instance of any one method? Maybe someone has 2 or more FaceBooks, etc.

So, instead of having 6 or 7 canned methods I have ten variable methods. Each method has a method and an address, so that's 20 custom fields I added to the profile and then I disabled I/O for all the stock address fields. Granted, a deeper and more normalized approach would include a separate table altogether. None the less, the new fields all operate in a much more efficient manner so the HTML for presentations and form submissions can be handled with the same small loop. The only case specific consideration is how to construct the anchor in the address, if any.

The methods use a combo box that itemizes all the possible contact types. Therefore, if someone has 6 different personal web sites they can specify them all by making 6 Web Site method selections and supplying the individual addresses for each. Likewise, the same system accommodates someone with 3 MySpace pages and 4 FaceBook personalities, etc. Only those items containing both a method and an address are broadcast. All methods can be edited normally.

Also, I might add that the e-mail addresses published in Kunena profiles are not JavaScript obfuscated, which is something I added where appropriate using the format $link_url = JHTML::_("email.cloak", $link_email);