Xcache authentication \ avatars \ karma ?

[a10]

2.1 looking very promising, and fast. Running php 5.5. A few questions:

- During upgrade am being asked for Xcache authentication user\pw (have to kill the upgrade at that stage, but the upgrade went trough anyway on the (test)forum. Same Xcache authentication appears when trying to "Empty the file cache". No such authentication on 2.0.9 same host (but php 5.3).

- Attachments got upgraded fine (with a new .dat ending) and works fine, but the 2.0.9 uploaded avatars don't work, they are present on the server, in specific Upload directory, path is correct. New upload of avatars work.

- Any way to convert karma into likes ?

Thanks

[Bigguy]

xcache must have a username and password installed through SSH to use it right. (AFAIK) But, xcache for me at least is not working right now due to a token verification failure. I am therefore using file based caching until that bug gets fixed....if it is a bug and just not my server.

[Arantor]

I don't know about xcache, not sure about the avatar stuff, it worked for me on my limited testing, but it's possible it needs tweaking.

As for the last question, answer is no. Karma out of the box in 2.0 is logged against a person more than posts. The total is stored per person on a permanent basis but only against a given post for a short period (like an hour) after which time there is no way to know whether a given user gave karma for any post, so no way to convert that into likes.

[Illori]

xcache must have a username and password installed through SSH to use it right. (AFAIK) But, xcache for me at least is not working right now due to a token verification failure. I am therefore using file based caching until that bug gets fixed....if it is a bug and just not my server.

since that bug has not been reported on github, i wonder how the devs will be aware there is a bug that needs to be fixed...

[a10]

Thanks for replying.  I'll just forget whatever I don't know about xcache, and regarding karma some mod or something may appear one day.

Some digging about avatars, here's an example, link called avatar_membername where the picture should be, clicking view image (FF) = not found, as 2.1 tries to open forum/avatars2/avatar_1234.png, while the file on the server is forum/avatars2/avatar_1234_9248850.jpg

Applies to all avatars from 2.0.9, truncates the filename and calls them .png

[Bigguy]

xcache must have a username and password installed through SSH to use it right. (AFAIK) But, xcache for me at least is not working right now due to a token verification failure. I am therefore using file based caching until that bug gets fixed....if it is a bug and just not my server.

since that bug has not been reported on github, i wonder how the devs will be aware there is a bug that needs to be fixed...

As a matter of fact one of the Devs does know about it so I was told and is going to get to it. Not sure when that is and I forget who told me that but that is all of what I know.

[Arantor]

Would it still not be better to have it on Github where *all* the devs can be aware of it, and also track changes related to it?

[Bigguy]

Oldies knows about it and so does Dragoon. From what the post says that I just link illori to.

[Arantor]

So? Oldies has had a bug fix from me for several months that has not gone into either 2.0 or 2.1. Communication is *essential* for a project of this size and complexity. Which is why a central tracking system like Github is also essential both in existence and continued use thereof.

[Bigguy]

I have also mentioned it once again today in another topic along with mentioning that the only serious bug left on github with 2.1 is paid subs and I thought both of those issues should be fixed before 2.1 beta 2. Not going to discuss this anymore in someone else's thread. They know about it and that is as far as it goes for me. I tried to help find bugs earlier and that didn't go all to well so ....ya. This will end this conversation for me.

[Arantor]

Funny, both of the issues actually marked as beta 2 on Github are unrelated to paid subs.

But seriously, Github IS the venue for marking any actual bugs including all of the ones raised in this thread, and not using the tools for the job is actually hurting, not helping, the process.

[Bigguy]

I figured something else out about this today. Seems there is no problem with xcache at all. I run my server in fastcgi and I guess the "xcache.admin.enable_auth" part of xcache has to be turned off in the php.ini file if you are going to run xcache. Hope that made sense.

[Dragooon]

So? Oldies has had a bug fix from me for several months that has not gone into either 2.0 or 2.1. Communication is *essential* for a project of this size and complexity. Which is why a central tracking system like Github is also essential both in existence and continued use thereof.

What bug and fix?

[Arantor]

I already spoke to Oldies about this.

(And now you see my point about communication.)

[Bigguy]

Oldies had stated this awhile ago. This is what I am referring to:

http://www.simplemachines.org/community/index.php?topic=527041.msg3751464#msg3751464

[Dragooon]

I figured something else out about this today. Seems there is no problem with xcache at all. I run my server in fastcgi and I guess the "xcache.admin.enable_auth" part of xcache has to be turned off in the php.ini file if you are going to run xcache. Hope that made sense.

So I'm confused, is this a server bug or is it something we can fix?

[Arantor]

The xcache bug is not something that can be fixed in SMF because it's a PHP configuration issue... at least that's the conclusion Oldiesmann and I came to when we talked about it yesterday.

[Bigguy]

Since I have been running 2.1 I installed xcache on my server. (This was awhile ago) It has never worked right because I always got a token verification error when trying to clear cache. Yesterday, after doing a bit of research I figured out that running xcache on a server with fastcgi does not work right. (Not sure where I read that but did post it on Github) So I had to disable xcache.admin.enable_auth in php.ini. What that does is stop xcache from asking for the username and password all the time. After disabling that, xcache worked perfect. No token failure at all.  This is what I read:

Xcache authentication will not work with CGI or FastCGI. This is not an issue unique to Xcache; it is a limitation of PHP in CGI mode, as the PHP_AUTH variables are not available

Hope that helps to explain it. All I was told in the beginning was that this would be fixed soon. No one told me it was not a problem in SMF, just that it would be fixed soon.

[Oldiesmann]

I wouldn't have guessed that the token verification issue was related to the xcache auth issue really. I'm glad that fixed it though.