I have seen a number of threads relating to problems with the http_referer function, that is getting the "Why am I being redirected here?" page. I just had some odd experience with it too.

Yesterday I upgraded a XOOPS 2.2.1 site (a rebuild of my existing 2.0.13 site) to 2.2.3afinal. After doing so and correcting the footer to show the correct version, when I logged in as admin using the existing password I got that infamous "Why am I....." page. I was logged in and could move around the site, use admin menu, etc. If I logged out and tried to log in again I got an incorrect password message. Strangely, if I logged in using a test account (ordinary user) I did not get the http_referer message. That was from the same local machine (a Mac running OS X 10.4) and I had not changed any firewall settings. It is behind a hardware firewall.

Finally I decided to request a new password for my admin account (using the Forgot Password link). After getting it, I can now log in using that new password without getting the http_referer message. I seems that there is something odd about that function.

I am not sure if this helps anyone, but some of those seeing this message may want to try requesting a new password.

Barry Cooper

Thanks Rowdie,

You are quite right and I completely forgot that the footer text is "hard coded" in the preferences/meta tags. I don't look at that very often.

It seems to me that it would be nice if the footer version number could be dynamically inserted as it is for admin pages. Failing that, it would be useful if a reminder to change it were inserted in the upgrade instructions.

Thanks again,

Barry

Hi all,

I just upgraded a new site I am developing from 2.2.1 to 2.2.3 using the final patch downloaded from the xoops.org. After upgrading, using the procedure outlined in the docs, the site still shows:

Powered by XOOPS 2.2.1 © 2001-2005 The XOOPS Project

The XOOPS 2.2.1 is a link and it points to xoops.org.cn (Xoops China). The XOOPS Project is also a link, pointing to xoops.org. I have seen comments on the News page related to the 2.2.3 upgrade about 2.0.13 sites not showing the correct version, but no explanation. The includes/version.php file does show the correct version.

Can anyone explain why the incorrect version is sill showing and why that first link points to XOOPS china?

Thanks,

Barry Cooper

I've been thinking a bit more about this problem, where the _XK_FONT etc appears as the default in the drop down menus, as indicated by gediminasbyt in an earlier post and confirmed by my testing. This obviously is a problem with the defined values for _XK_FONT etc. not being substituted. It appears to be due to changes in the way Koivi is coded, and a real fix presumably will require some coding changes in AMS.

I confirmed this by doing the following:

I copied the contents of /class/xoopseditor/koivi into a new folder /class/wysiwyg in my XOOPS 2.2 test site. I left the path to Koivi as it originally was in AMS (that is, class/wysigwyg). I set AMS to use Koivi, with the result that the drop downs show _XK_FONT etc. This shows that the problem is not due to the path to the values, but to changes in Koivi.

I then deleted that folder /class/wysiwyg from my 2.2 site and copied the wysiwyg folder from my XOOPS 2.0.13 site into /class on the XOOPS 2.2 site. I found that AMS set to use Koivi then worked properly.

Thus, a work around for this problem is to copy the wysiwyg folder from XOOPS 2.0.13 into the /class folder in a 2.2 site. Leave the /class/xoopseditor/koivi folder intact so that News or other modules can use it.

Ideally, Mith, or perhaps some other programmer, can tell us the changes required in AMS 4.2 to make it work properly with the koivi version in XOOPS 2.2. I will try to look through the code, but I don't think I'm enough of a programmer to figure out the changes required.

Barry

I have to admit that I hadn't tested this solution, but was passing on advice provided to me when I asked about using Koivi in AMS under XOOPS 2.2. The reason I hadn't tested it is that I still run my live site under 2.0.13, waiting for a proven stable version of 2.2 to be released.

I did just now test the solution on a test 2.2 site and find the same problem that you do. I don't know enough about how AMS is coded to determine what the error is. The best person to ask would be Mithrandir, as he coded AMS. He may be too busy with working on the (hopefully) soon to be released stable 2.2.X to attend to this. Perhaps you can try to contact him to ask about it. Or, perhaps one of the programmers out there can suggest why this is happening.

Barry

It's a path issue. The needed modification to the AMS code is in the forums on the AMS site. It was posted by Ryan in response to my question on the same topic. Here is his answer:

edit AMS/include/storyform.inc.php

Find the lines:
if ($xoopsModuleConfig['editor'] == "koivi" && file_exists(XOOPS_ROOT_PATH."/class/wysiwyg/formwysiwygtextarea.php")) {
include_once XOOPS_ROOT_PATH."/class/wysiwyg/formwysiwygtextarea.php";


replace "wysiwyg" in the path names with "xoopseditor/koivi" so they look like this:
if ($xoopsModuleConfig['editor'] == "koivi" && file_exists(XOOPS_ROOT_PATH."/class/xoopseditor/koivi/formwysiwygtextarea.php")) {
include_once XOOPS_ROOT_PATH."/class/xoopseditor/koivi/formwysiwygtextarea.php";

I looked good on Firefox, that is, clicking on the thumb brought up the full image. There is debug info at the bottom of the page. Looks like you have php debug turned on in prefs and it should be turned off on a live site.

Barry

What version of xcGal are you using? There is a new version for XOOPS 2.2 available on XOOPS Dev that has some improvements over the original version and works with XOOPS 2.2.

Barry

Have you checked Gallery under Module Access rights for anonymous users? (i.e. in XOOPS 2.0.x, under Admin/System/Groups/Anonymous users. Also make sure Anonymous Users can view pics is set to yes in the module admin settings.

Barry

Under Main Menu, Extended Profiles/Change password. That is, Change Password is a separate link from Edit Account.

Barry