Not having ANY error messages pop up...

unset() destroys a variable. isset() determines if a variable has been given a value.

Wait, I just noticed something. In the snippet file, there’s this code...



Now, in...

function __construct($LanguageArray, $dateFormat = ’%A %B %d, %Y at %I:%M %p’, $UserImageSettings = ’105000,100,100’, $type = ’simple’)
{
require_once ’manager/includes/controls/class.phpmailer.php’;
$this->LanguageArray = $LanguageArray;
$this->DateFormat = $dateFormat;
$this->UserImageSettings = $UserImageSettings;
$this->Type = $type;
}

Everything, except $LanguageArray, matches something inside of of the snipet file. Maybe it’s just me, but that seems kinda weird that $LanguageArray isn’t refrenced at all in the snippet file, and vice-versa for $lang in the snippet file.



With that, I see how $wlpe_lang is is refrenced. But it still doesn’t make sense that I can’t see how these three variables are being linked together. From what I can see, it’s getting passed into LanguageArray okay, but it can’t "see" in the snippet that $lang = en, and therefore gives a blank error, because it already unset the "There was an error" text. Basically, I think WLPE is looking for a value called &LanguageArray in the snippet file, and obviously cannot find it.

Unless I’m misreading this, and you just meant $LanguageArray to equal itself, so it inputs whatever error it needs.

(I’m starting to understand the script a little more by doing this...you coded this very well, I have to admit. )

I appreciate your eagerness to help Soshite, but I think you misunderstand a lot about how PHP works.

$wlpe_lang is an ARRAY. It is defined in the FILE "lang/en.php" and REFERENCED as "$lang" in the snippet code (the name of the variable is irrelevant. This is an important concept in this case, so write it down. The name of the $lang variable as it exists in the snippet code is irrelevant.

WebLoginPE, as defnined in the FILE "webloginpe.class.php", is a PHP Class... a blueprint for an object. It is a definition of instance variables and methods that can be used to create many, many unique objects with similar characteristics. In the case of the WebLoginPE "snippet", we are only creating one instance of WebLoginPE (with all it’s instance variables and methods), and we are identifying it as $wlpe. You can see that $wlpe is an OBJECT because the first time it is mentioned, it is seen in this context:

Let me break it down. This code is saying "Hey... I have a variable here with the name $wlpe, and here is what I want it to represent". It is given a value.
The PHP keyword "new" tells the script that you are going to instantiate a ’new instance’ of an object... as defined by the class with the name following the word "new". in this case It is saying the $wlpe variable is an object with all the properties that a "WebLoginPE" object can have (it’s a lot! ).

But wait... the parameters. Oh yes... WebLoginPE (the class (or blueprint, if you will)) needs a little info before it can willy nilly create a new object out of itself. In it’s case, it needs an array of language specific strings to work with (referenced in the class using the instance variable "$LanguageArray"). It needs a date format to format date and time strings (referenced in the class as the instance variable "$DateFormat"). It also needs the user image settings, and the type of WebLoginPE it is going to grow up to be (you can see the names in the __constructor() function).

Now, if you create your own snippet using the WebLoginPE class, you are going to want to specify these parameters.
You may have a language array in a variable called $pintoBeans, and a date format in a variable called $mySocks and the user image settings in a variable called $iLoveKittens and they type in a variable called $loginType.

You would set a variable to hold the WebLoginPE object like this:


You see, the class does not care WTF you call the variables, it is the information in them that matters.

In the WebLoginPE class, I changed the names of variables and methods MANY, MANY times before releasing it. Sometimes the variable names in the parameters no longer exactly match the name of the instance variable that they are going to be stored in, but after reading this, I am sure you now understand that the name of the variable does not matter... Unless you spell it wrong LOL!

-sD-
Dr. Scotty Delicious, DFPA.

I see. That clears up a LOT of the questions I had, then.

So, taking what you said into consideration, this is what I think must be happening...

--------------------------------------

After altering the path to the lang/en.php file, I know WLPE is, at least, finding the file (since it gave an error when it couldn’t find it, after I altered the first dir text). And [+wlpe.message+] is working, because it replaces it with the code...



So, then, [+wlpe.message.text+] isn’t being parsed right, because it’s not showing the error message that’s loaded in the function MessageTemplate. At least, with this info, I understand more what’s controlling the error message, so with any luck, I might just be able to find what’s causing this.

Since your install is working fine, this might be some weird issue with my server that’s causing it, possibly. I dunno what it could be, though.

EDIT: I dunno what could be causing my issue here. In the two areas I’ve tinkered around in, if something was altered, it caused the error message not to show up, meaning that how it is right now is technically right. So I assume this must be an issue with either my MODx install or my server.

It can’t be class.phpmailer.php, because then the data format wouldn’t be showing up properly, I think.

EDIT 2: I used the [^s^] timing tag, just to make sure it wasn’t being cached. As I thought, it was being drawn from the database. Something odd I noticed, though --- in the Online users area in Reports->System Info, instead of Wilhelm, which is the name I’m using for my fullname and username, it’s showing Albel Nox, which is the very first one I used to begin with. Dunno why it’s doing that.

Scotty: Could you show me how to change the LanguageArray[X] into a text string? That way, I could see if there’s an issue of my server not even being able to parse the FormatMessage command. Basically, I want to be able to type in the error message manually, to check to see if it works if it’s given directly.

Scotty, I figured out how to do that. Now, when I changed the non-image filetype upload error for the avatar to this...



It showed up, which is great, because we know MessageTemplate isn’t the problem at all, like I thought. For some reason, LanguageArray isn’t being parsed right, and can’t read the matching lang string in /lang/en.php. Do you have any idea why this isn’t working?

I could go and replace every error message using this method, but I’d rather not have to do if I don’t have to. Since you coded the script, I’d think you’d know why this isn’t working.

I added a ZIP of the webloginpe.classphp file I’m using, in case I made an error in that function, and you noticed it.

@soshite:
I am not going to download the zip file, but I think that now if you are sure the error is that the $wlpe_lang array is not getting properly stored as $LanguageArray in the __construct() method, then maybe you could try hard coding the language array into the construct.

include ’full/path/to/assets/snippets/webloginpe/lang/en.php’;
$this->LanguageArray = $wlpe_lang;

Is there any way that you could try it on another server or a home LAMP setup to see if it is a server issue or if it is your snippet call or template or something. Maybe it is a server issue?

-sD-
Dr. Scotty Delicious, DFPA

Scotty, I had to do this to get it to work...



So does that mean that my MODx base path was not getting set right? Because I had to change both that AND the LanguageArray to get it to work. It wouldn’t work without both of them.

So part of it was my sever path, and another was WLPE’s coding? The server issue didn’t suprise me, since it was a pain in the a** to get SMF’s FTP access to work when I used it because of that issue. But since only the server fix didn’t solve it, that should make the wlpe_lang issue a bugfix, I’d think.

Sorry to butt in again, but, I noticed __construct() was being discussed. If this is to work in PHP 4, you will need an old PHP 4 style constructor to manually call $this->__construct() or it will never execute. Mind you, I haven’t looked at the code, so I’m just guessing here...

And actually it would be better to use the PHP 4 constructor altogether, as PHP 5 will automatically fall back to it.

@soshite:
Not exactly.
There seems to be something seriously f***ed up with your server. Who is your host?

The snippet code takes the array $wlpe_lang and passes it to the construct to be stored in an instance variable as $LanguageArray.

It is done this way for a very specific reason. So anyone can translate the language file and use the &lang parameter to set their language file to be used by the class.

What you have done by implementing my suggestion is to hard code the language file into the class. I am glad this works for you, but this can not be considered a fix because it breaks multi-lingual ability.

Without having access to your server, I can only speculate, but I think that when when the snippet "includes" the language file and passes the $wlpe_lang array to the construct, something is getting lost.

Since this is an isolated incident (either it is only happening on your account on your shared server or your web host in general, and no one else is experiencing this "issue" or at least no one else is reporting it), I think it is safe to say this is not a WebLoginPE bug.

Please keep in mind that I am not a programmer by profession, simply a hobbyist. I do this in my spare time because I like MODx and web design. I saw the jQuery ThickBox and thought about how wonderfully cool it would be to have an AJAX type login (see the ThickBox AJAX Content demo), So I began coding a snippet to allow me to do that. Along the way I started to think that this *might* be useful to other people as well, so I released it as a MODx snippet. I really do hope that it will be useful, but I cannot guarantee that it will work for everyone on every server environment. It is GPL, so please feel free to modify it to as you have done to suit your needs, but unless you want to pay me to do custom code work for you then you are just going to have to understand that as a spare time coder I can’t force your server to work with my free code.

@OpenGeek.

Good point. This started out as a PHP5 script, but I think you are correct about ditching the __construct method all together. Less chance for a transcription error.

-sD-
Dr. Scotty Delicious, DFPA.

Scotty, since including it directly worked, instead of having MODBASEPATH (I forget the exact structure), I just input the full URL I used to get it to work? If this worked, you could just say something like, "If you do not have error messages appearing, replace the MODXBASEPATH with the full FTP address to your server.", or something close to that.

BTW, was changing $LanguageArray to $wlpe_lang really necessary, or is it one of those "It doesn’t matter what you name it..." kind-of-things, and in changing all of those values, I *thought* I needed both to get it to work?

As for my server, I am hosted on Gamespy. They had some hacker attacks a few years ago, so there’s probably some settings that got turned on that affect some scripts. But I get unlimited space/bandwith/download space, plus it costs me nothing (and I can now run Google Ads on it), so those perks outweight the issues I occasionally have.

EDIT: Yep. It seems when the language file is included in the snippet code, my server couldn’t include it right, which caused the issue. $LanguageArray didn’t even matter. So it was just an issue of the include not being done right. Amazing how two lines of code can mess up an entire script.

Quote from: Soshite at Sep 28, 2007, 09:51 PM

Scotty, since including it directly worked, instead of having MODBASEPATH (I forget the exact structure), I just input the full URL I used to get it to work? If this worked, you could just say something like, "If you do not have error messages appearing, replace the MODXBASEPATH with the full FTP address to your server.", or something close to that.

BTW, was changing $LanguageArray to $wlpe_lang really necessary, or is it one of those "It doesn’t matter what you name it..." kind-of-things, and in changing all of those values, I *thought* I needed both to get it to work?

As for my server, I am hosted on Gamespy. They had some hacker attacks a few years ago, so there’s probably some settings that got turned on that affect some scripts. But I get unlimited space/bandwith/download space, plus it costs me nothing (and I can now run Google Ads on it), so those perks outweight the issues I occasionally have.

$wlpe_lang is an array of language specific strings stored in an external file. by including the file in the snippet, you gain access to use the $wlpe_lang array. the __construct() takes this array and stores it as an "instance variable" (named LanguageArray). $LangaugeArray is now a "copy" of the $wlpe_lang array. Storing it as an instance variable gives all the methods and other instance variables of the class access to it. For example, in the Register() method there are many language specific strings for errors, success, etc... They use $this->LanguageArray to access those strings instead of having to manually include the language file for use in that methods scope each time you wanted to send a string to the screen.

-sD-
Dr. Scotty Delicious, DFPA.