Xcache authentication \ avatars \ karma ?

Started by a10, November 24, 2014, 03:15:16 PM

Previous topic - Next topic

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
2.0.19, php 8.0.30, MariaDB 10.6.18. Mods: Contact Page, Like Posts, Responsive Curve, Search Focus Dropdown, Add Join Date to Post.

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.
Holder of controversial views, all of which my own.


Illori

Quote from: Bigguy on November 24, 2014, 04:30:56 PM
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
2.0.19, php 8.0.30, MariaDB 10.6.18. Mods: Contact Page, Like Posts, Responsive Curve, Search Focus Dropdown, Add Join Date to Post.

Bigguy

Quote from: Illori on November 24, 2014, 05:35:32 PM
Quote from: Bigguy on November 24, 2014, 04:30:56 PM
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?
Holder of controversial views, all of which my own.


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.
Holder of controversial views, all of which my own.


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.
Holder of controversial views, all of which my own.


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

Quote from: Arantor on November 24, 2014, 06:18:55 PM
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? :P

Arantor

I already spoke to Oldies about this.

(And now you see my point about communication.)
Holder of controversial views, all of which my own.


Bigguy


Dragooon

Quote from: Bigguy on November 25, 2014, 06:37:00 PM
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.
Holder of controversial views, all of which my own.


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.
Michael Eshom
Christian Metal Fans

Advertisement: