Well I was able to figure out this issue....to some degree.

I was using a custom php.ini file in the main XOOPS directory to change some settings like max_file_upload. But it was the presence of this php.ini that was causing the sessions to not be stored on the server, although Im not exactly sure why.
Once I removed the php.ini file, the sessions worked fine (logging in and staying logged in). However even if I had a blank php.ini file, it would cause session problems.

Strange - but I will just have to work with the hosting company to figure that out.

I have a working XOOPS website (in fact lots of them) on a server running PHP4.4 but I plan to move these sites to a different host running PHP5. I copied over one of these sites but have experienced a number of issues related to PHP5. I was able to fix all but one of the issues by overriding settings in a custom php.ini file. The last and most frustrating problem is the website being unable to retain session information belonging to valid logged in user/administrator.

I know that there are many different threads on the forums pertaining to this issue and I have tried all the suggested fixes.
-- cleared files in cache/ and templates_c/
-- cleared browser cookies and sessions for the website
-- emptied session table and also repaired it even though it didnt have problems. Sessions are being added to that table just fine.
-- ensured server timezone was set correctly
-- toggled between setting use_mysession to be 1 and 0
-- toggled activating and deactivating Protector module
-- toggling the autologin feature on and off
-- turned on debug mode to see if that could provide clues
-- toggled between having session.save_path to be a valid writable folder under the account for this website and also setting it to the default setting
-- ensured session.use_cookies was set to On
-- I dont have a "regenerate" setting in kernel/session.php
-- setting HTTP_REFERER value in xoopssecurity.php to be true

The version of XOOPS is 2.2 and as I say the exact same website works fine on a server running PHP4.4 - no login problems.

I have tried logging in using IE7 and FF2, and setting my cookies very low. I have also tried stepping through the XOOPS code in common.php and checklogin.php and outputting the $_SESSION and $_COOKIE array during the login and redirection process. The $_COOKIE array always contains the correct information. But the $_SESSION array initially contains all the valid logged in user information (when checklogin.php has finished executing), but then on the redirected page, the $_SESSION array is empty (outputting the array from common.php). I believe thats where the problem lies as XOOPS has to check elements fromt the $_SESSION array to ensure its a valid logged in users with correct permissions for modules.

Perhaps there is another php.ini setting I need to change to get this working? Or including updated code for session.php from a newer version of Xoops?

Looking forward to the 2.x release.

I just emailed you a couple of screenshots of my multiMenu hack.

Thanks for the fast response solo71 and for explaining the issue -- it had me completely stumped.

multiMenu truly is a powerful module.

I did run into another problem with using the multimenu_dyn_vert.html template.

I can change colors and background images for the menu from my theme stylesheet e.g. #mainmenu
However, I cant control the colors or background images for a submenu of links, and the parent link for the submenu. These seem to be hardcoded into the multimenu_dyn_vert.html template. It seems the javascript in the template needs to have some of the style info right there, rather than reference it from the theme stylesheet.

Perhaps Im missing something and it can be controlled from the theme stylesheet, or maybe you can suggest another hack or workaround?

Thanks for your help!

Oh and here is a suggestion of an enhancement for a future version. When adding a link to the menu, to give the user the option to choose a link to an existing content page from a dropdown, or to choose a link to any of the installed modules from another dropdown. I implemented this on my end since I was using wfchannel for adding content pages on my sites and the administrators who manage the sites aint very techie so I had to give them the ability to quickly add a content page and make it live in a specific place on the main menu.

I should also mention that when the cache multiMenu file changes to be multimenu_list.html, if I go to the Menu Blocks admin area and view the options set for the multiMenu block, they are set correctly -- the Block Format is set to "Drop down vertical".

Im using XOOPS v2.2.4 with multiMenu v1.8 on a Linux server running PHP 4.4.2.

It works great and for my main menu block im using the "Drop down Vertical" which utilises this template multimenu_dyn_vert.html.

I have the cache set to be 1 week, but if someone makes changes to the menu, I added a hack so it would refresh the cache.
using this XOOPS function:
xoops_template_clear_module_cache($xoopsModule->mid());

That all works fine. However I have been noticing that on a few of the websites Ive built with multiMenu like this, it sometimes displays a different block template, for no apparent reason - multimenu_list.html.

Here is the serialized array from the top of the multiMenu block that gets cached successfully.
Quote:

And here is what the cache file changes to on a website where Ive noticed this issue.
Quote:

Note that the arrays are from 2 separate websites, but they are built identical in every way. And Ive seen the issue occur on about 4 of my websites all built like this.

Anyone have an idea why this would happen, or how I could go about tracking down this bug?

Just an update to this topic.

I realized I didnt need to hack xoopsmailer.php to implement sending emails in text/html, text/plain or multipart/alternative formats. I could set variables directly in class.phpmailer.php.

To send an email as plain text
$xoopsMailer->multimailer->IsHTML(false);

To send an email as html
$xoopsMailer->multimailer->IsHTML(true);

To send an email as html with a text version included (multipart email)
$xoopsMailer->multimailer->AltBody = "text version of email";

To make a text version of a html message, I use the Html2Text class.

Sometimes bounced emails dont go to the Sender of the email -- this is due to the Return-Path being the default server email address and thats where the bounces endup (e.g. nobody@servername.com).

To force the Return-path variable:
$xoopsMailer->multimailer->Sender = $xoopsConfig[adminmail];

Perhaps someone may find this info useful.

My hacking of evennews turned it into a module that worked a bit different. I just wanted a newsletter module where I could send emails to the current users in the system, if they had the user_mailok preference set to Yes in their profile. For someone to subscribe or unsubscribe from the newsletter they just have to toggle that setting.

So I wouldnt have any need of importing users. On a side note, I will be coming up with a way to import users from a csv file into a XOOPS database - I have about 200 sites that I have to convert from phpnuke to XOOPS and transfer all the users. What makes that tricky is the user_profile table which has changeable columns. Not sure if there is a XOOPS import hack out there?

And for queueing newsletters here is the rough logic Im using.
When someone creates a newsletter, it is saved as a draft (mail_queue='N'). Then when they want to send it, they change that setting to 'Y'. I then wrote a phpscript which runs as a cron job every couple of hours. It connect to the XOOPS database and searches to see if there are any newsletter entries with mail_queue='Y'. If there is, I log myself in as an administrator using curl so I can execute a index.php?op=process_message script in the evennews admin directory. The process_message operation then sends out the newsletter to all recipients and it wont breakdown because the script is running as a cron rather than from the browser.

As I say a heavily hacked evennews. Perhap down the road I will add some failsafes so if the apache server restarted while the cron was running that I would have logged who all received the newsletter and who was still to receive it so the script could run again. Phplist uses a similar approach although thats a much more complex mailing list application.

Sure - adding it to the mysql.sql is the way to go.

I think its a great idea to have an enhanced PM module.
Features where there already are released hacks:
-- option to send an email notification when a pm has been received
-- option to have a javascript popup appear saying you have a new pm when you login to the website.

One major hack I will be tackling in the coming months is coming up with a way to group users into subgroups. e.g. - administrator selects specific users to be part of a board of directors group or a committee. Also the ability of users to add themselves to say a book group. I would add these fields via the profiles module (Im using XOOPS v2.2.4).
Then for private messages if a user is part of a committee group they could send a pm to all the other members of the group by selecting that from a dropdown menu. Same would be true for users wanting to send a book review to other members of the book club as an example. I would also hack the evennews module to send newsletters to specific groups as well.

Ive heavily hacked my evennews module where I can preview a newsletter Im created, saving drafts and adding newsletters to a mail queue. The latter is how I got around the issue of sending a newsletter to a large number of recipients since a cron job runs every couple of hours and processes queued newsletters. Also I dont think the smartmail would suit my clients needs right now - too complex for non-techies to figure out.

Ive found it tough to troubleshoot the PM module when you get that dreaded empty Errors when trying to send a PM.
The Errors display when the $pm_handler->insert($pm) function fails but Ive never been able to follow the breadcrumbs succesfully to echo details about why it wouldnt insert.

But in this case, I believe if you add an integer column called "dohtml" to your priv_msgs table, you wont get the error.

Once you add the column, try adding the line back into pm/class/privmessage.php
--> $this->initVar("dohtml", XOBJ_DTYPE_INT, 1, false);

The other confusing thing about the PM module is that in some parts of pm/pmlite.php it makes a call to
--> $pm_handler =& xoops_getmodulehandler('privmessage');
and in another part to
--> $pm_handler =& xoops_gethandler('privmessage');
which refers to kernel/privmessage.php

Although that could be due to some other hacks I made to that module.

Hope that helps.