Page 5 of 10

Posted: Sun Mar 12, 2006 1:10 pm
by Emperor_Slain
T0ny wrote:
Emperor_Slain wrote: I am sure you can use both mods, I just added the _fillfix line in the correct places.


This MOD and the Autofill fix MOD are both cures for the same problem. Although using both will work, you only need to use one of them.

Yeah I figured, well thanks anyway.

Posted: Mon Mar 13, 2006 8:55 pm
by m3mn0n
omg this mod kicks ass :)

been waiting for something like this, great work.

Posted: Sun Mar 19, 2006 4:54 am
by Jackanape
Works like a charm!

Congratulations on a great first outing for a mod--I look forward to more!

Posted: Sat Mar 25, 2006 6:37 pm
by MistaObvious
Hate to be the bearer of bad news, but I think I've discovered another bug.

I can't honestly say why it won't work, but for some reason the user_edit_body.tpl won't work using "user_name" instead of "username" on my board. Instead of anything appearing wrong, after hitting submit when changing someone's profile it just goes right back to the "Look up user" page. At first, I didn't realize that this was a problem as there was no actual error, but after noticing on the boards that a user I've changed a rank for hadn't actually had his rank changed, I started looking into it.

It's quite possible that this is all a conflict with another mod, and for that I'm unsure of which. I would greatly appreciate help in fixing this and/or figuring out what mod, if any, conflicts with this one.

My current mod list:
a-m_color_management_2.2.0em
allow_bbcode_smiles_in_forum_description_1.0.2
Easy_assign_user_to_groups_1-0-6
error_avatar_101
fix_firefox_pwd_1.2.0
flash_mod_2.0.11
google_bbcode_120a
moderator_tags_130
Multi_BBCode
pm_popup_blocker_fix_100
quicksearch_301
report_posts_1.2.3c
smilies_order-1_0_0
sqr-1.3.2
wrap (disabled)
birthdays2.0.0a
easymod_0.3.0
sqr-1.3.2

Mods that effected user_edit_body.tpl:
Easy assign user to groups 1.0.6
Force Word Wrapping - Configurator 1.0.16
Super Quick Reply 1.3.2
Fix For The Firefox "Remember Passwords" Problem 1.2.0
Birthdays 2.0.0a

Posted: Sun Mar 26, 2006 6:02 pm
by amoun
Just to say thanks to all.

Came here from a link provided by JinFury on my topic http://www.phpbb.com/phpBB/viewtopic.php?t=376417

Have just installed "fix_firefox_pwd_1.2.0.mod" and everything seems fine.

Probably unrelated but the 'look up' list still has all the old user names, although the 'users' have been deleted. I didn't notice this before the MOD, but it may have been the same.

All the best

Amoun

Posted: Mon Mar 27, 2006 12:47 pm
by T0ny
MistaObvious wrote: after hitting submit when changing someone's profile it just goes right back to the "Look up user" page.


Sounds like one of your MODs has removed/corrupted the 'mode' hidden field. When you edit a users details, view the source of the right-hand frame and see if you can find

Code: Select all

<input type="hidden" name="mode" value="save" />
If that's not the problem, does changing the name="user_name" back to name="username" correct the problem?

Posted: Mon Mar 27, 2006 2:22 pm
by MistaObvious
The hidden mode=save line is still there.

It corrects the problem of saving, but unfortunately it negates the fix for FireFox. That's actually how I disabled the fix until I could get an answer as to how to fix it.

Posted: Mon Mar 27, 2006 4:12 pm
by T0ny
MistaObvious wrote: The hidden mode=save line is still there.

It corrects the problem of saving, but unfortunately it negates the fix for FireFox. That's actually how I disabled the fix until I could get an answer as to how to fix it.


can you PM me the full contents of:

admin/admin_users.php

and

templates/subSilver/admin/user_edit_body.tpl

Then I'll have a look and see if I can find what is going wrong.

Posted: Mon Mar 27, 2006 10:21 pm
by MistaObvious
I decided to move this back to this post in case anyone else runs across this problem. Thus far we've found no problems in the code and have tried running a variable test to see what's being passed for the username.

So I added the following to admin_users.php:

Code: Select all

define('IN_PHPBB', 1);

if ( ( isset($HTTP_POST_VARS['user_name']) ) & ( !isset($HTTP_POST_VARS['username']) ) )
{
	$HTTP_POST_VARS['username'] = $HTTP_POST_VARS['user_name'];
}

// testing the username variables
echo ("user_name: " . $HTTP_POST_VARS['user_name'] . "; username: " . $HTTP_POST_VARS['username']);
No matter what mode was set to (whether I was editing, saving or whatever), both of these variables came back blank.

So I thought perhaps it would be a good idea to try something a little different and added some javascript to send the value of $user_name to $username in the template:

Code: Select all

<script language="jscript" type="text/jscript">
<!--
function getUserName() {
	
form.username.value = form.user_name.value;

}

//-->
</script>

<form action="{S_PROFILE_ACTION}" {S_FORM_ENCTYPE} method="post" onsubmit="getUserName()"><table width="98%" cellspacing="1" cellpadding="4" border="0" align="center" class="forumline">
	<tr> 
	  <th class="thHead" colspan="2">{L_REGISTRATION_INFO}</th>
	</tr>
	<tr> 
	  <td class="row2" colspan="2"><span class="gensmall">{L_ITEMS_REQUIRED}</span></td>
	</tr>
	<tr> 
	  <td class="row1" width="38%"><span class="gen">{L_USERNAME}: *</span></td>
	  <td class="row2"> 
		<input class="post" type="text" name="user_name" size="35" maxlength="40" value="{USERNAME}" />
		<input type="hidden" name="username" value="" />
I now get an error that this username is already taken. As I'm writing this, I'm thinking that this has been something discussed already in this thread, so I'll go back and investigate. But there's the latest.

EDIT: I think I know why I'm getting that error. It could be because it's not properly setting the "username" field with what's in "user_name", so it's sending the $username variable as being empty. Since I'm completely behind in my JavaScript (prolly been about 6 years since I've last used it) I can't think of anything else to do.

perhaps try this instead of a javascript

Posted: Tue Mar 28, 2006 4:25 am
by eternalsword
perhaps try this to see if you are getting the variables passed correctly


Code: Select all

<form action="{S_PROFILE_ACTION}" {S_FORM_ENCTYPE} method="post"><table width="98%" cellspacing="1" cellpadding="4" border="0" align="center" class="forumline">
   <tr>
     <th class="thHead" colspan="2">{L_REGISTRATION_INFO}</th>
   </tr>
   <tr>
     <td class="row2" colspan="2"><span class="gensmall">{L_ITEMS_REQUIRED}</span></td>
   </tr>
   <tr>
     <td class="row1" width="38%"><span class="gen">{L_USERNAME}: *</span></td>
     <td class="row2">
      <input class="post" type="text" name="user_name" size="35" maxlength="40" value="{USERNAME}" />
      <input type="hidden" name="username" value="variable_test" /> 
I know this would not send what was entered into the field to the post, but at least you could test to see if the variable is getting passed at all. If you still come up with the username is already taken error, then the issue is not in the passing of the variables from the form.

Posted: Tue Mar 28, 2006 10:14 am
by T0ny
MistaObvious wrote: I decided to move this back to this post in case anyone else runs across this problem. Thus far we've found no problems in the code and have tried running a variable test to see what's being passed for the username.


Try repeating the variable test, but with the test before the MOD code i.e.

Code: Select all

define('IN_PHPBB', 1);

// testing the username variables
echo ("user_name: " . $HTTP_POST_VARS['user_name'] . "; username: " . $HTTP_POST_VARS['username']);

if ( ( isset($HTTP_POST_VARS['user_name']) ) & ( !isset($HTTP_POST_VARS['username']) ) )
{
   $HTTP_POST_VARS['username'] = $HTTP_POST_VARS['user_name'];
}
If that gives the same result then for some reason the variable isn't being passed to the script, otherwise the MOD code is at fault.

Posted: Tue Mar 28, 2006 12:18 pm
by MistaObvious
Y'know, honestly, I tried the test as you mentioned, but without using "user_name" in the tpl and it still comes up blank. There's one catch, tho... it still updates the user info when using "username" instead of "user_name" even tho we can't see what the variables are.

I'm wondering if it's possible our test is not quite right. I'm gonna have to break out my PHP book and see what I can see.

Posted: Tue Mar 28, 2006 1:27 pm
by T0ny
I think (hope) I may have found the problem. PHP5 has a new directive 'register_long_arrays' (default: on). If this has been set to off, then the $HTTP_POST_VARS[] array won't exist. In this case phpbb makes $HTTP_POST_VARS[] a copy of $_POST[] (in common.php), but this is done after this MOD has made it's changes to $HTTP_POST_VARS[] and so those changes are over-written.

If I'm right, then moving the MOD code in admin_users.php down to just below the 'require pagestart' line i.e.

Code: Select all

require('./pagestart.' . $phpEx);

if ( ( isset($HTTP_POST_VARS['user_name']) ) & ( !isset($HTTP_POST_VARS['username']) ) )
{ 
	$HTTP_POST_VARS['username'] = $HTTP_POST_VARS['user_name'];
}
and making a similar change to admin/admin_ug_auth.php thus:

Code: Select all


require('./pagestart.' . $phpEx);

if ( ( isset($HTTP_POST_VARS['user_name']) ) & ( !isset($HTTP_POST_VARS['username']) ) )
{ 
	$HTTP_POST_VARS['username'] = $HTTP_POST_VARS['user_name'];
}
should cure the problem :!:

Give this a go and let me know if it works :)

Posted: Tue Mar 28, 2006 3:56 pm
by MistaObvious
You rock, my friend. That did the trick and everything's running as it should. Like others have said, you are a class act for keeping up with your mod support like this.

As a suggestion, just to avoid others having issues, you might consider updating the mod release to reflect these changes as I'm sure I'm not the only one who'll have PHP5 configured as such. That is, unless it breaks the code for those who aren't configured that way, but I don't see how that could be an issue.

Anyway, thanks again for your great efforts here. ;)

Posted: Tue Mar 28, 2006 4:21 pm
by T0ny
Another satisfied customer :D

Glad that worked, and you're right about updating the MOD, I'm going to do it a soon as I've had time to check that the new code locations won't cause more problem.