My SMF installation clearly got damaged in the move from one server to another. I'm going to get it straightened out and then bring in the new versions of the components again. Looking forward to having a working bridge again.

I uninstalled the bridge to try to put in this patch, and I think I'll just leave it uninstalled.

I've had trouble ever since I installed with it not remembering the login cookie correctly - you'd come back and it would seem to remember you, but when you clicked the Forums button you would have to log in again to see the logged-in-only forums or post. I was hoping it might be better with the upgrade, so I upped to Joomla 1.0.8 and installed the new bridge.

It was bridging okay, but none of the templates would render correctly, framed or unframed - tables were nested wrong and the whole thing would cascade off the side if you nested it, otherwise the tables ran together in big blocks unnested. I know you're working hard on the thing, and I wish I had more time to experiment with it, but I'm doing volunteer stuff with it myself.

I'll probably try again later, but this version was a clear step backward for me. I just moved my site to a new server, so maybe something didn't make the leap correctly. I know I'm having trouble getting templates to act right in SMF, with or without the bridge (I select a new one, but the old one still displays), but I guess it's one variable I can remove to try to get it straightened out.

Well, I give up. I reversed all that out and tried again and still got a good link. Is it intermittent? The first notification I got today had arguments only. I'm going home.

Here's what appears to be the real fix...

Somehow $mosurl doesn't seem to have a value when it needs it, so it replaces $scripturl with null. I coded a test fix like this:


That seemed to work, so next I tried this:That seemed to work as well, I get full Joomla URL's back to the private messages in my email notifications. It's odd because the first reference to $mosurl is the global declaration, so it should have taken the global value.

Myself, I always tend to go through the $GLOBALS array. I've had difficulty with global declarations in the past that I solved by using the array.

Thanks, cowboy, giving it a try.

I noticed in vim that a couple of the lines in that area (like the global declaration) showed up with ^M EOL codes, while most don't. Are those odd carriage returns affecting the script evaluation?

I accidentally created a problem like this for myself yesterday. While trying to correct a different problem, I tried changing the URL for SMF (in SMF settings) from:

http://www.mydomain.com/community

To just:

http://www.mydomain.com

The bridge still appeared to work, but it seemed to break the path to image files, etc. I reset the domain path in SMF and avatars showed up again.

Don't know if your problem is similar or not.

My Forum Error Log is full of these:Does does this matter?

It's in the login form:

Yeah, I just had another user with the same problem with a very simple login name, so my earlier assumption was a bad one.

I had the forum up before I had the Joomla wrapper, so I think some people might be going in through the forum signup instead of the Joomla signup, so that's where it's falling apart.

This seems to have to do with a bug that I was getting ready to report, but I haven't ascertained that it has not already been reported...

I would lay odds that your new user had a space in their name. SMF doesn't like the spaces (or dashes, etc.), but Joomla does. I had a user create a new account with a space in the name, so the Joomla account got created, but the SMF account didn't. The email went out without domain links in it. Attempting to sync users will fail for the SMF illegal names.

Testing with a valid SMF name, I got the right validation email with complete links.

The account creation page needs to be set up to disallow spaces and other SMF illegal characters if the Joomla account is created first. Maybe there's a tweak to make it reg through SMF first to escape this.