By mwu on
Why is there no list of variables in api docs? There are functions and constants, but not variables. Where do I learn about the variables? My understanding is that there is a module called variables, but it's 4.6 only.
My problem is this. I enabled a small piece of code called emailchange.module that I got from a forum thread. It works in that the user cannot change their email address.
But now it turns out no one can. User 1 cannot add an user. And the module is currently DISABLED.
I thought I better study each variable carefully to see what's going on. But how do I learn about the variables?
I tried typing $op in api docs but the search returned nothing
(I also searched "drupal" "variables" but too many other things, of course.)
function emailchange_help($section) {
switch ($section) {
case 'admin/modules#description':
// This description is shown in the listing at admin/modules.
return t('This prevents users from changing their email address.');
}
}
function emailchange_user($op, &$edit, &$user, $category = NULL) {
switch ($op) {
case 'validate':
//lets validate the user info
if ($_POST['edit']['mail'] != $user->mail) {
form_set_error('mail', t('You cannot change your email right now.'));
}
break;
}
}
Comments
$op is a really common
$op is a really common thing, and I have a feeling the answer you want is not in the variables, but here, try google search, if you really must. You can select the api site by doing this
site:api.drupal.org $opAnisa.
-----------------------------------------------------------
Kindness builds stronger bonds than necessity.
www.animecards.org - 18,000 card scans and counting!
-----------------------------------------------------------
hook functions and arguments
$op is an example of an argument and the function implements one of the drupal hooks. You can find more about the drupal hooks at http://api.drupal.org/api/4.7/group/hooks and in general more about drupal APIs at http://api.drupal.org/api/4.7
By the way to overcome the problem you are finding I think you want to change
to
which will only do the validation if the email address is already set.
If you want to prevent people from changing their own email address (i.e. people with permission and root can) you might try this version
thank you very much
thank you
Globals?
I think the guy has got a point - I can't find any info about global variables and classes. One can look through the code (and this is what I do), but documentation would be handy. Maybe I am missing something?
--
http://www.baryudin.com
I Agree we need a searchable list of Drupal variables
By variables mean things like $pid, $mid, $content and $node. Which are currently only explained as parameters of a function in the API.
Yes, I can read through the functions themselves. Yes I can trace teh variables and deduce what they do from their output.
But it would be so much more intuitive to be able to type $mid into the API search and have something like
------
$mid - The menu ID of a menu item
Used In These functions.
menu_get_item
etc.
etc.
And maybe even some trace code you would use to find the $mid of the page you were on.
-----
IMHO this would make customizing sooooo much easier and the general learning curve allot less steep.
agree
completely agree
now if we can only get a core developer to think about this
The problem...
...Is that the internal variables used in a given function should not and do not matter outside of that function. If I write a function that takes an incoming menu ID and renders it, I can use $mid as the variable name, or $myMenuId, or $foobar, or $somethingithoughtwouldbecool. In some cases, very commonly used variable names like $nid are defacto conventions, but there's nothing to keep you from using something else -- and no code that calls your functions would have to know.
There's a very small handful of *global* variables, like $user and $form_values, that are used in specific parts of the system. Other than those, though, documenting internal variable names would be a waste of time -- and there would be millions of such variables to document throughout the Drupal core.
--
Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
form_values
while it's global you are better not using it directly, you get it as a parameter when you need it :)
This thread is meaningless, someone does not know what's variable scope and what's a parameter. I saw code before which did
foo($op = 'bar')which also showed similar cluelessness.--
The news is Now Public | Drupal development: making the world better, one patch at a time.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
right,
so why can't the global variables be documented?
Because...
Because to the best of my knowlege, only three or four (tops) are in use by Drupal. Only one (global $user) is really acceptable for general use in modules and other development code, and folks still want to replace it with a centralized function like get_current_user().
Other global variables, like $form_values, are used only in VERY specific portions of code by 'core' drupal functions. They have to be globals for certain things to work properly, but messing around with them in your own code is an invitation for disaster. In those situations, the rule of thumb is 'if you can't figure out what's going on with variable X by examining the code, don't think about using it.'
When all is said and done, one of the principles of drupal development seems to be, 'Don't use global variables to pass information. Instead, use well-named functions to encapsulate the information and let other code call those functions when they need it.' It's a principle that works really well, and helps to protect developers from a tangly rats' nest of variables floating all over the place.
--
Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Well, I think Drupal
Well, I think Drupal developers should either document those globals which are acceptable for usage by everyone ($user and others) or create functions, which return appropriate objects (as mentioned by someone earlier).
--
http://www.baryudin.com
I think you're missing the
I think you're missing the point, perhaps because the original request isn't phrased well.
The naming conventions for variables (whether arguments or locals) should be documented. There aren't millions of them, just a few dozen I'd guess. It would certainly help new people get started. The fact that the conventions can't be enforced by PHP isn't an issue; there are other unenfoceable coding conventions that are documented.
Gary Feldman
Yes, this would really be
Yes, this would really be awesome! My problem is: I have quite well understood hooks and how to look up the parameters used. I have a hard time, however, finding out about any of the variables other than $node. For eample, I would like to know what I can do with the $view variable, as e.g. used in an example here http://drupal.org/node/83415. That's real hard to get to know everything I can do. I mean it is not the coding part, but rather knowing which variables contain what...
Missed the point
While I agree with most posters here that even asking the question shows a total lack of understanding of the concept of scoped variables as function arguments, there IS hope.
Regarding the variables passed in to the functions, It's to be found in the documentation.
In the hooks.
In hook nodeapi() you see i giant list of values that $op is expected to have in that context. Once you read that "$op is what kind of action is being performed" you can imagine that in other contexts, other actions may be expected.
In hook_form_alter($form_id,$form) ... well one it the form ID and one is the form structure itself. Questions?
The hooks have the best docs.
Contributed hook implimentations, and especially snippets do NOT always repeat the variable declarations as they are required to have the same order and have the same meaning as those original prototypes. They are not required to have the same name, but usually do for convention.
Globals
The only global I've ever had to invoke (and even then it was probably avoidable) is $q - which is the query string passed in to the Drupal handler.
As mentioned, the global $user is accessed a few times by modules that need it. If you can't guess, it represents the current user definition.
Internally, a seach of the docs (try it yourself Reveals some usage of
And some internal stuff to do with the database ($active_db, $db_prefix, $db_url, $last_query) and pager.
That's pretty much it.
Conventions
There's a few more, but they are all meant to be read in scope, they are not rules.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards