Hey, you just go to modules admin and there you can set in what order to display links to those modules in the main menu. Number "0" (zero) means it wont show. Everything from 1 to X is the "weight" for setting order.

As for multimenu, just follow your instict. It's basically clicking on one of the numbered multimenu buttons in multimenu admin and adding links inthere by clicking "add". Then you just have to be sure to enable their display and position in blocks administration.

So, has there been *anyone* that had this problem and resolved it? If yes, you're most wanted! Please share with us what you did.

I have tried with the register.php file from profile module 2.2.2, but it's the same as with the fixed register.php of 2.2.3 (fixed for that "three characters" bug by phppp).

I am currently using the XOOPS 2.2.2 with the profile module of 2.2.3. I tried with the whole 2.2.2 profile module and it didn't work, and the problem started when I has both XOOPS and profile mod at 2.2.3 so..

You know how bad it is not being able to welcome new users on the site. It breaks my heart, especially when a guy emails me saying "please help!".

This is unbelieveable.

It actually worked before yesterday and then I got an email via contact form from a visitor trying to register getting that "three characters" error. Then I search, find a fix and apply it and here we are: "Could not register new user." - out of the blue sky and with absolutely no fix or solution in sight.

God I wish I didn't upgrade to 2.2 branch. It's killing me.

I'm thinking of uploading 2.2.2 over 2.2.3 files and updating system module as a way to revert back to 2.2.2. Would this shortcut be safe?

Thanks
Daniel

For downgrading from XOOPS 2.2.3 to XOOPS 2.2.2 or 2.2.1 I think the process I described would work as I think there's no database structure changes between 2.2.x releases. But yes, in case where you downgrade to a previous branch (being 2.0.x) the situation is different.

Anyway, I know now that I should have waited with upgrades as I would probably have no problems that I have now. Autologin would work with the old hack on the old version, so would all the modules including weblog and its blocks. I just thought it wont hurt as those releases were marked as stable. I should have thought better though and think of the possibility of module incompatibilities.

Still, yes, the bright side is that if we didn't move we wouldn't be able to report problems for fixing that would advance the 2.2 branch. In every evil some good, right!

Cheers
Daniel

That's smart. I also have mysqldump cronjob running every midnight, but I don't backup all physicall files so often. It's harder to do when you're on dial up connection as you have to download/upload quite big files to save your backup at home or restore in case trouble comes. And my hosting space isn't abundant either..

Of course, there are still measures I can take. For example, I don't need to backup all XOOPS files since most of them are from the XOOPS release tarballs and never changed except when upgrading to a new release. So, this leaves me with only data files (such as these images) and XOOPS files that have been applied a hack or modification of some kind that I want to save. I can just download these periodically and save them to my disk, with the periodic DB download. That should work for dial up people.

Well, I guess that if I decide to do a clean install I will do this way:

1) Temporary close the site to freeze all content additions.

2) Determine what files need to be backed up and what are the locations they have to be put in after the clean install. Also note what modules are installed.

3) Backup and download all these files as well as the full database backup.

4) Delete everything

5) Install XOOPS again

6) Install all modules that were installed before.

7) Fill in the database from the DB backup

8) Put back the backed up data and hacked files in locations they were before (or just reapply the hacks to existing ones on the new installation).

9) Reopen the site

That should be it. After this I would have a clean XOOPS install with the old DB and data, modules and hacks, but without any glitches that were creeped in the old install.

That's quite some work though and some things should be ensured before as well, such as the means of restoring a database. Just manually reinserting the database through something like phpMyAdmin would take ages. Maybe something like backpack can help with that.

I'm not sure if I'll do that yet. It may very well be that I can resolve remaining glitches without a clean install at least with the new and more stable releases of XOOPS. My site is currently functional actually (autologin and weblog recent block not working, but the site as a whole is OK).

Thanks
Daniel

It would seem that 2.2.3 version of XOOPS is pretty unpredictable or just "buggy" would be the right term. Some things work for some folks, others don't have such luck. It must be because of slight differences in their server setups.

For example, 2.2 autologin hack by GIJOE apparently worked for many people, but not for me, despite the fact that I've done everything right to implement it and checked it a few times. In the same sense, a weblog module by Tohokuaiki seems to be working for some people (as reported), but to me it's giving an internal server error whenever loading its "recent blog entires" block.

And although I have't discovered any other major bugs, as things stand I wouldn't be surprised if more are hiding somewhere. All of this gives me that "dirty" feeling (you probably know what I mean) and makes me wish to just install the whole site from the start, clean off, the last most stable 2.2 relese (that would probably be 2.2.2).

I'll have to take a look at that backpack thing. If it would be possible to securely back *everything* up, delete XOOPS and install it again cleanly and then just reinsert all data with absolutely no loss or risk I would actually like to do it.

The installation I currently have active is a year old (from the beginning actually) and I've learned XOOPS as I used it on the fly. This time it would just feel good and right if I install it clean once again and based on that experience run it as cleanly as possible and with no mistakes.

So, I have one question about these database backups.. What about images? As far as I know images are actually stored in directories on the server so I should watch not to delete them so I don't loose stuff like users avatars, image gallery images and such, right?

Thanks
Daniel

I just posted the problem on tohokuaiki's site as well.

The thing is that I've been using weBLog for a year now and I got plenty of entries there so it wouldn't really be so easy to switch to another module (if possible at all). Besides, I have checked for alternative blogging modules before and none really met my needs. WeBLog is the only one that does.

I really hope he can support XOOPS 2.2.x fully as I think this module means alot to many XOOPS users. It would be a shame for all of us to be cut off in favor of the japanese XOOPS only.

Thanks for reply
Daniel

Alright, I've looked at error logs (yeah, should have done that earlier) and the actual internal server error is: "Premature end of script headers".

It happens every time I try to load the "Recent Blog Entries" block of weBLog module, even if it is to preview it in the templates admin section.

I've searched these forums and found one another thread mentioning this error, but the only answer was to google for it. Well, I did and apparently the problem is usually tracked down and eventually resolved by testing the faulty script standalone and then modifying it. There are also mentions of possible permission problems.

However, permissions are alright and I have checked that. Running the faulty script standalone is much more complicated (if at all possible) with XOOPS, because what we are dealing with here is not just one script, but a whole set of php scripts running of which any (but presumably belonging to weblog module) could cause a problem. And then again, it seems that the problem may as much be in the template file, but that's where this whole thing starts to confuse me.

All I basically know is that any page that attempts to load the weblog module's "Recent Blog Entries" block spews out an Internal Server Error: Premature end of script headers, and that it is not due to wrong permissions and such.

So, all you php gurus, what could be wrong? I read that other people have no problems using this module on their 2.2 powered sites. What could it be in mine that is giving me this problem?

(Also, the GIJOE's autologin hack doesn't work in my case while it works on other sites, while we're at it. Does my site have ghosts?)

Please, if anyone can shed any light on this I would be greatful.

Thank you
Daniel

Anyone?

It would help if anyone knows and would say what could cause a block to cause an "Internal Server Error" message preventing the page on which the block was loaded from opening?

Could it be a conflict between that and another block? Any suspects? The page is the homepage onhttp://www.libervis.com (the "recent blog entries" block has been disabled because of this so it doesn't show there, but you can see other blocks it might conflict with).

Thank you
Daniel