Not having ANY error messages pop up...

Quote from: Dr. at Sep 23, 2007, 08:31 PM

Soshite, I have tried this all week and the only way I can get it to not pop up errors is if I take the [+wlpe.message+] placeholder out. I don’t know why this is happening to you, but I bet it is something simple that your are doing with the snippet call or template or something. Sorry, I don’t have a lot of time to look at it right now.

-sD-
Dr. Scotty Delicious DFPA.

Hmm...if it was an error, I apparently would have made it in a lot of the pages.

Just to make sure, all I should need to "create" the error message output is the [+wlpe.message+]?

If I could ask quick --- what PHP5 version did you use to debug v1.3.0 when you were developing it? If it’s a error specific to the version on my server, I might be able to use that to debug what’s going on, if it has to deal with that.

Quote from: Soshite at Sep 23, 2007, 10:36 PM

Hmm...if it was an error, I apparently would have made it in a lot of the pages.

Just to make sure, all I should need to "create" the error message output is the [+wlpe.message+]?

If you want to see messages from WebLoginPE on the page, you have to have the placeholder [+wlpe.message+] somewhere in your custom template (it is in all the default templates). This is simply a delegation to WebLoginPE on where to place the messages. Without this placeholder, WebLoginPE will not have a designated area to write messages and no messages will be returned to the page.

Quote from: Soshite at Sep 23, 2007, 10:36 PM

If I could ask quick --- what PHP5 version did you use to debug v1.3.0 when you were developing it? If it’s a error specific to the version on my server, I might be able to use that to debug what’s going on, if it has to deal with that.

There is no more PHP5 specific code in WebLoginPE. It doesn’t matter what version above 4.4.x you use.

-sD-
Dr. Scotty Delicious, DFPA.

Hmm...if I didn’t make a mistake, I wouldn’t be suprised if it’s a issue with a setting on the server. Gamespy’s server has had some...quirks...in the past.

In any case, I’ll try to look into what’s causing this myself. Thanks for your help so far.

Just observing here, but could it possibly be that you are putting your placeholder in a cacheable part of a page?

Quote from: OpenGeek at Sep 24, 2007, 02:18 AM

Just observing here, but could it possibly be that you are putting your placeholder in a cacheable part of a page?

You mean the [+wlpe.message+]?

****...that needs to be [!wlpe.message!], doesn’t it? If that’s the case...I can’t believe I didn’t notice that. I’ll try that to make sure, but it might be a good idea for Scotty to make a note of this in the instructions, if it’s true.

Quote from: Soshite at Sep 25, 2007, 02:22 AM

You mean the [+wlpe.message+]?

****...that needs to be [!wlpe.message!], doesn’t it? If that’s the case...I can’t believe I didn’t notice that. I’ll try that to make sure, but it might be a good idea for Scotty to make a note of this in the instructions, if it’s true.

I think you really misunderstood what OpenGeek said!

-sD-
Dr. Scotty Delicious, DFPA.

Quote from: Soshite at Sep 25, 2007, 02:28 AM

Oh, I see. Though, then his idea wouldn’t work, since WLPE is already being called as uncached in the snippet call. Or is he meaning that then, the page itself would need to be uncached?

MODx does a tremendous job on reducing database calls whenever possible through it’s flexible caching system. entire pages can be cached, or sections of pages, for example the output of a snippet.

I believe he was suggesting that you make sure that the error message placeholder is not in a cacheable part of the output. If it is, MODx will try to load that from the cache instead of displaying the new data.

-sD-
Dr. Scotty Delicious, DFPA.

Tried my little "idea", which didn’t work. x_x

And I just checked the page again. The snippet is called uncached, and the page is uncached. I dunno what the hell is causing this (because if the snippet was wrong, the script wouldn’t function. It doesn’t make sense, because nothing in this page is being cached. And Opera is set to always check for a newer version of a document, so it can’t be that either.

So the only logical conclusion is that WLPE can’t access the language files for some odd reason (hence why I can’t get any of the language variables to appear in the places they are supposed to appear). Scotty, is there any code for WLPE that can test quickly if WLPE is accessing the /lang/en.php file --- if I could do that, I could detect whether WLPE is unable to get the language file (which would be a easy fix, I’d imagine), or if it’s a bigger problem, where it’s finding the variable, but can’t process it correctly.

Or where it loads the language variable from (so I could purposefully mess with it and see if it gives an error when it’s location is changed).

And just to rule out this, does the /lang/en.php need to be CHMOD a certain way (like 777)? I’d doubt that’s it, but it doesn’t hurt to check.

Well, at least I know now it isn’t the lang file not being found, because I changed the line to find the lang file in the snippet call, and it created a MODx critical error.

So the issue must lie somewhere inside of the class file, since WLPE on the MODx Manager must "know" the snippet is trying to put an error in there (else, why would it create the <div> and <p> tags around the error handler?). I’ll try poking around in the file and see what I can find.

(Something odd that just happened when I was tinkering around with the class file. Remember that parser error I got before, on Line 39? I changed unset to isset for the heck of it in around Line 184 -- the 2nd one in the error message function. Dunno what it means, though.)

unset and isset are very dissimilar functions. They are not interchangeable, and although you may get a "unique" effect, what you will not get when you interchange them is a working script.

-sD-
Dr. Scotty Delicious, DFPA.