Hi, I am new to using MedaWiki, and when I try to make a sysop from this page: http://www.glossologia.org/wiki/index.php/Special:Makesysop
I get the following text:
"Error: could not submit form
This form is used by bureaucrats to turn ordinary users into administrators. Type the name of the user in the box and press the button to make the user an administrator
*User "Bob" could not be made into a sysop. (Did you enter the name correctly?)" *
I am using MySQL and phpMyAdmin if that helps any. Runs fine for me except for this problem. Thanks.
On Jan 10, 2005, at 1:41 PM, Justin M. Gregg wrote:
Hi, I am new to using MedaWiki, and when I try to make a sysop from this page: http://www.glossologia.org/wiki/index.php/Special:Makesysop
I get the following text:
[snip]
*User "Bob" could not be made into a sysop. (Did you enter the name correctly?)"
I notice at this page: http://www.glossologia.org/wiki/index.php/Special:Listusers there is no user account "Bob" listed.
-- brion vibber (brion @ pobox.com)
hey all,
this isn't directly on topic, but it does relate to mediawiki..
What do people use for a command-line IDE in debugging mediawiki, aside from dbg (http:/dd.cron.ru/dbg)
I've just about given up on the command line debugger there - and was wondering whether php has any plans on integrating one into the php-suite, as perl does..
Ed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Peschko wrote: | What do people use for a command-line IDE in debugging mediawiki, aside | from dbg (http:/dd.cron.ru/dbg)
Mostly I just try to stick in a stack trace at fatal errors (as a general rule, using wfDebugDieBacktrace()) and occasionally slip in a temporary var_dump to see additional variable state. Crude, yes.
| I've just about given up on the command line debugger there - and was wondering | whether php has any plans on integrating one into the php-suite, as perl does..
Zend (the developer of PHP) sells a proprietary, commercial IDE with an integrated debugger. Honestly I doubt they're interested in cutting into that market by integrating debugging tools into the open-source PHP core. They've so far kept bytecode caching out of the standard PHP distribution as well.
- -- brion vibber (brion @ pobox.com)
On Sat, Jan 29, 2005 at 06:31:49PM -0800, Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Peschko wrote: | What do people use for a command-line IDE in debugging mediawiki, aside | from dbg (http:/dd.cron.ru/dbg)
Mostly I just try to stick in a stack trace at fatal errors (as a general rule, using wfDebugDieBacktrace()) and occasionally slip in a temporary var_dump to see additional variable state. Crude, yes.
| I've just about given up on the command line debugger there - and was wondering | whether php has any plans on integrating one into the php-suite, as perl does..
Zend (the developer of PHP) sells a proprietary, commercial IDE with an integrated debugger. Honestly I doubt they're interested in cutting into that market by integrating debugging tools into the open-source PHP core. They've so far kept bytecode caching out of the standard PHP distribution as well.
bleah.
The wfDebugDieBacktrace() call would work well if you knew the codebase already, what I was looking for was using the debugger as a teaching tool, to see how the code was structured, and step through what it does.
And I *hate* graphical debugging environments. Do you know if Zend, dbg, or any other IDE provides a cli interface?
I've tried php-dev, but they are noticably silent on the whole issue...
Ed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Peschko wrote: | On Sat, Jan 29, 2005 at 06:31:49PM -0800, Brion Vibber wrote: |>Mostly I just try to stick in a stack trace at fatal errors (as a |>general rule, using wfDebugDieBacktrace()) and occasionally slip in a |>temporary var_dump to see additional variable state. Crude, yes. |> | bleah. | | The wfDebugDieBacktrace() call would work well if you knew the codebase already, | what I was looking for was using the debugger as a teaching tool, to see | how the code was structured, and step through what it does.
Well, that's a rather different question; you asked what we use for debugging.
| And I *hate* graphical debugging environments. Do you know if Zend, dbg, or any | other IDE provides a cli interface? | | I've tried php-dev, but they are noticably silent on the whole issue...
Basically, the world of debugging PHP is a really crappy world, which can barely support life.
- -- brion vibber (brion @ pobox.com)
On Mon, Jan 31, 2005 at 01:24:23PM -0800, Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Peschko wrote: | On Sat, Jan 29, 2005 at 06:31:49PM -0800, Brion Vibber wrote: |>Mostly I just try to stick in a stack trace at fatal errors (as a |>general rule, using wfDebugDieBacktrace()) and occasionally slip in a |>temporary var_dump to see additional variable state. Crude, yes. |> | bleah. | | The wfDebugDieBacktrace() call would work well if you knew the codebase already, | what I was looking for was using the debugger as a teaching tool, to see | how the code was structured, and step through what it does.
Well, that's a rather different question; you asked what we use for debugging.
well, just to be pedantic, I asked for a command line debugging environment. I didn't tell you what I was planning on using it for.. ;-)
I suppose I could go through the UML class diagrams and assorted docs on wikipedia's code, but that sure as hell doesn't take the place of stepping through something to see how it works.
I'm going to talk to the dbg developer at NuSphere, and see if he can't update the dbg_cli project.
Ed
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Peschko wrote: <snip>
I suppose I could go through the UML class diagrams and assorted docs on wikipedia's code, but that sure as hell doesn't take the place of stepping through something to see how it works.
<snip>
We don't have UML class diagrams for the momment. It is on my todo list if I ever finish my university UML course :o)
- -- Ashar Voultoiz - WP++++ http://en.wikipedia.org/wiki/User:Hashar http://www.livejournal.com/community/wikitech/ Servers in trouble ? noc (at) wikimedia (dot) org
hey all,
a couple of questions - what are the prerequisites for running 'index.php' at the command line, eg:
php index.php
doesn't seem to do anything.
Ultimately, I'd like to be able to run index.php sans browser and be able to debug based on the output that comes to standard out...
Ed
(ps -
is there a good class pretty printer for php? I noticed that - unlike perl - var_export, print_r, etc, don't seem to handle classes very well. I'd like to be able to say:
var_export($class_reference);
and have php print out all the associated class variables and object variables. )
Edward Peschko wrote:
a couple of questions - what are the prerequisites for running 'index.php' at the command line, eg:
php index.php
doesn't seem to do anything.
Ultimately, I'd like to be able to run index.php sans browser and be able to debug based on the output that comes to standard out...
MediaWiki's index.php is the web entry point and is not designed to be run from the command line. You'll see no output because it's trying to use an HTTP header to redirect you to the main page; the header is not output by PHP's command-line mode.
If you want to run the web output from a command line, you should use a PHP CGI executable and set up the CGI environment variables.
There are numerous command-line entry points in the maintenance subdirectory, mostly special-purpose. eval.php provides a somewhat primitive interactive PHP interpreter within the active MediaWiki code environment. (You really, really want PHP compiled with readline support or this will be painful. :)
is there a good class pretty printer for php? I noticed that - unlike perl - var_export, print_r, etc, don't seem to handle classes very well. I'd like to be able to say:
var_export($class_reference);
and have php print out all the associated class variables and object variables.
So far as I know, PHP doesn't have metaclasses or class variables.
-- brion vibber (brion @ pobox.com)
On Wed, Feb 23, 2005 at 11:22:59PM -0800, Brion Vibber wrote:
Edward Peschko wrote:
a couple of questions - what are the prerequisites for running 'index.php' at the command line, eg:
php index.php
doesn't seem to do anything.
Ultimately, I'd like to be able to run index.php sans browser and be able to debug based on the output that comes to standard out...
MediaWiki's index.php is the web entry point and is not designed to be run from the command line. You'll see no output because it's trying to use an HTTP header to redirect you to the main page; the header is not output by PHP's command-line mode.
If you want to run the web output from a command line, you should use a PHP CGI executable and set up the CGI environment variables.
so I get these environmental variables from what - the $_ENV and $_SERVER globals? Php seems to have sliced the environmental variables into these two associative arrays.. What if I need the variables in $_COOKIE and $_GET and $_POST?
There are numerous command-line entry points in the maintenance subdirectory, mostly special-purpose. eval.php provides a somewhat primitive interactive PHP interpreter within the active MediaWiki code environment. (You really, really want PHP compiled with readline support or this will be painful. :)
I'll give it a whirl, but I'm skeptical. I just tried it, got a '>' as a prompt, hit one question mark (to get help) and it seemed to spawn an infinite loop of '>' prompts.
and have php print out all the associated class variables and object variables.
So far as I know, PHP doesn't have metaclasses or class variables.
well, I mis-spoke. I wanted to print out an object, and it so happens that the object I chose (WebRequest) doesn't seem to have any object variables *or* class variables.
Ed
( ps -
ok, preemptive apology for the following rant, but this is seriously screwed up:
"As of PHP 4.3.0, the name, location and existence of the CLI/CGI binaries will differ depending on how PHP is installed on your system. By default when executing make, both the CGI and CLI ere built and placed as sapi/cgi/php and sapi/cli/php, and NOTE THAT BOTH ARE NAMED PHP."
It goes on to say that based on what compile options you use, ONE OR THE OTHER php is installed as php, and the other is ignored. I have a php CLI version, but I guess the wiki I installed works because I've got a:
LoadModule php5_module libexec/libphp5.so
statement inside of my httpd.conf, but this is just too whacked out. They've bifurcated the php code base whether or not your in a command line world or a CGI world??
Just curious, but why was php chosen in the first place? The more I look, the more php seems to be tied together with little bits of string and glue.. why not python or mod_perl, or ruby? Or, even c/C++, or *shudder* java? )
Edward Peschko wrote:
On Wed, Feb 23, 2005 at 11:22:59PM -0800, Brion Vibber wrote:
If you want to run the web output from a command line, you should use a PHP CGI executable and set up the CGI environment variables.
so I get these environmental variables from what - the $_ENV and $_SERVER globals? Php seems to have sliced the environmental variables into these two associative arrays.. What if I need the variables in $_COOKIE and $_GET and $_POST?
If you google I'm sure you can find lots of documentation on how CGI works. CGI (Common Gateway Protocol) is the classic standard way for web servers to send request information to programs, which then return some HTTP header lines, a blank, and the resulting data to send back to the client. The web server gives request information to the CGI program by means of environment variables.
PHP can operate in a web server either as a built-in module (eg mod_php in Apache) or as a CGI program, in which case it will interpret the CGI environment variables and present data to the script in $_GET, $_POST, $_COOKIE, $_SERVER, etc.
There are numerous command-line entry points in the maintenance subdirectory, mostly special-purpose. eval.php provides a somewhat primitive interactive PHP interpreter within the active MediaWiki code environment. (You really, really want PHP compiled with readline support or this will be painful. :)
I'll give it a whirl, but I'm skeptical. I just tried it, got a '>' as a prompt, hit one question mark (to get help) and it seemed to spawn an infinite loop of '>' prompts.
"?" is not a valid PHP statement.
[snip]
statement inside of my httpd.conf, but this is just too whacked out. They've bifurcated the php code base whether or not your in a command line world or a CGI world??
No, there's a single code base; they just chose some unfortunate naming for the front-end executables.
Just curious, but why was php chosen in the first place? The more I look, the more php seems to be tied together with little bits of string and glue.. why not python or mod_perl, or ruby? Or, even c/C++, or *shudder* java?
Why anything? You have to pick something, and somebody's going to bitch about it whatever it is. Perl in particular is twice as ugly as PHP. ;)
-- brion vibber (brion @ pobox.com)
works. CGI (Common Gateway Protocol) is the classic standard way for web servers to send request information to programs, which then return some HTTP header lines, a blank, and the resulting data to send back to the client. The web server gives request information to the CGI program by means of environment variables.
PHP can operate in a web server either as a built-in module (eg mod_php in Apache) or as a CGI program, in which case it will interpret the CGI environment variables and present data to the script in $_GET, $_POST, $_COOKIE, $_SERVER, etc.
let me rephrase the question - is there a particular point inside of index.php that I could snapshot, which would have all the variables needed for a given index.php query, and could I take these variables, set the appropriate CGI environment up, and then run it seamlessly?
Or is there going to be extra-environment information that I'm going to have to acquire (and massage) in order to make this work? I'm primarily thinking cookies here..
I'll give it a whirl, but I'm skeptical. I just tried it, got a '>' as a prompt, hit one question mark (to get help) and it seemed to spawn an infinite loop of '>' prompts.
"?" is not a valid PHP statement.
of course, but I would think that the appropriate response would be to emit a syntax error, not an infinite loop of '>'s . This just leads me to think that it might be not the most 'well-traveled' debugging environment.
No, there's a single code base; they just chose some unfortunate naming for the front-end executables.
... and made it rather difficult to have both flavors resident on your machine at the same time,
In particular (for those who google on CLI and CGI problems with php), to get both cli and cgi, I needed to configure and compile php twice, once --with-apxs=, and once without.
Just curious, but why was php chosen in the first place? The more I look, the more php seems to be tied together with little bits of string and glue.. why not python or mod_perl, or ruby? Or, even c/C++, or *shudder* java?
Why anything? You have to pick something, and somebody's going to bitch about it whatever it is. Perl in particular is twice as ugly as PHP. ;)
;) ok, lets just say that we respectfully disagree here. AFAICT, php is one huge winnebago class, which survives by quick access to a bunch of quick-to-use functionality without needing to import various modules. (perl is a winnebago too, but about 5 times smaller, and perl has much more powerful data manipulation methods.
Ed
Edward Peschko wrote:
let me rephrase the question - is there a particular point inside of index.php that I could snapshot, which would have all the variables needed for a given index.php query, and could I take these variables, set the appropriate CGI environment up, and then run it seamlessly?
At any point you could snarf data from $_GET, $_POST, $_COOKIES, and $_SERVER and store it for later use.
Or is there going to be extra-environment information that I'm going to have to acquire (and massage) in order to make this work? I'm primarily thinking cookies here..
A login session will store some information using PHP's session support, which is keyed by a cookie. By default, PHP stores session data in temporary files. See http://www.php.net/session
I'll give it a whirl, but I'm skeptical. I just tried it, got a '>' as a prompt, hit one question mark (to get help) and it seemed to spawn an infinite loop of '>' prompts.
"?" is not a valid PHP statement.
of course, but I would think that the appropriate response would be to emit a syntax error, not an infinite loop of '>'s . This just leads me to think that it might be not the most 'well-traveled' debugging environment.
You mean like this?
brion@rdaneel:/var/www/head/maintenance $ php eval.php
?
Parse error: parse error, unexpected '?' in /var/www/head/maintenance/eval.php(24) : eval()'d code on line 1 bool(false)
exit
brion@rdaneel:/var/www/head/maintenance $
-- brion vibber (brion @ pobox.com)
Or, even c/C++, or *shudder* java?
Some cavaliers (Timwi, Magnus, Manfred) have made oeil- lades in that direction, Ed; and a C engine would enable us to dish out pages, say, as a native Apache handler.
It's a big project, however; and the .php, being just functional enough, engenders a fatal inertia.
-- Peter Danenberg . wikisophia.org ..:
On Fri, Feb 25, 2005 at 12:48:18AM -0600, Peter Danenberg wrote:
Or, even c/C++, or *shudder* java?
Some cavaliers (Timwi, Magnus, Manfred) have made oeil-lades in that direction, Ed; and a C engine would enable us to dish out pages, say, as a native Apache handler.
It's a big project, however; and the .php, being justfunctional enough, engenders a fatal inertia.
hmm. would a C++ engine allow a native apache handler as well? Or even C#? I agree that C is the ubiquitous choice, but IMO mediawiki *does* benefit from being fairly OO, and with the right OO design mediawiki wouldn't box itself in a corner. Of course you can do OO in C, it just tends to get a little uglier.
Plus if C++ was chosen, you'd have all of boost to play with for parsing and other low-level data structure formatting..They've also got a pretty good threading library.
Ed
wikitech-l@lists.wikimedia.org