I was actually looking at this at one point but wasn't important enough at the time to mess with. This module could be integrated into profile and then use the profile information to merge with facebook. But as it is now it does log in as a user. I didn't mess with it for long. I wasn't sure if it was setting up a new xoops user or was just making a temporary one that only lived as long as they were connected.

Improve cookies to have different local species sessions when you are testing multiple systems and core, modules and themes.

This is because if I do the login for example locally on xoops 2.5.4 cannot do so on xoops 2.5.5 why xoops session 2.5.4 is cleared, and if I'm testing a module should I force you to log in again, resulting in the loss of the xoops section 2.5.5.

Not checked with those names are stored sessions, but I think it should be different for each system.

Quote:
I agree, as I was suffering from the same. Now I set the session names manually in Admin preferences, but it would be nice to have an unique cookie for each installation set by the system.

Quote:

I will remember this when I get to that part for the install...

Should be simple to randomize.

I am assuming the field we are talking about is the one in the System General Preferences named "Session_Name". Should the Name for user cookies be randomized as well? I believe both of these are used on the system and if you are testing a system out it may be a benefit to randomize both of these fields at install time.

And what type of randomization would we prefer? a 12 character randomly picked jumble of characters including all normally printable characters?

I normally change this to reflect the name of the site so I never saw an issue with it. But I can make sure it won't be an issue for new installs using the install script I am working on.. (Last class appears to be April 30th so It is plausible I should have the script ready for testing before end of May)

A CMS THAT ACTUALLY WORKS

It is advised to clear caches once in a while for performance reasons. Can this be automated? By using a cronjob would be nice, but having an autonome system (not depending on cron) within xoops would even be better. I'm not a programmer so I really don't know..., but could this be done?

There is such script already done, just someone have to port it. Auto clears cache on save, edit, delete, on time.

I don't mean just auto clear when administering a site. But automated without webmaster intervention. Or am I mistaken and is clearing caches at certain intervals not a good thing for performance?

The whole Idea of caches is if they work they save a lot of processor time and help bring pages up quickly. The first time a cached page is rendered it will render slowly but then after that any pages after that should render quicker.

I have not dealt with Caches yet to know how they are setup with Xoops but it does seem like flushing out caches would not be a bad thing. And hopefully a cron type item will be added to allow such things.

You CAN add something to your normal cron right now to clear these caches out on a daily basis and the only issue will be that your site will appear to be slower when first rendering.

Would make more sense to clear the cache when you install a new module or do something that may benefit from having the caches cleared out. Also due to the number of caches in the system you have to be concerned with the potential of disk fragmentation as well. (This is not an issue for Linux and some file systems. Probably also not an issue for some other systems either. But should be aware of if you are running a Windows system with a NTFS file system.)

Maybe even setup a cache refresh that will delete say 10% of the cache files starting with the oldest ones on a daily basis. This would keep you from refreshing all of your caches every day showing a slowdown and it would likely not even be noticed by any of your users.

Xoops need less memory consuption. If you have database with eg. 15000 articles in it it slows down, showing errors or something worse. I recently I've scripted 21000 articles in Xoops 2.5.5 (made cataloque of some institutions) and on localhost in php.ini it need at least 512mb to be set.