actions_max_stack
aggregator_allowed_html_tags
allow_insecure_uploads
cache_inc
filter_allowed_protocols
forum_block_num_active
forum_block_num_new
front_page_output
locale_cache_strings
menu_default_active_menus
mime_extension_mapping
search_tag_weights
session_inc
session_write_interval
simpletest_clear_results
taxonomy_terms_per_page_admin
update_fetch_url
I will work on this but there are quite a number of which even I never even heard of...
Comments
Comment #1
sunAwesome. Tracking.
Comment #2
douggreen CreditAttribution: douggreen commentedsearch_tag_weights stores the scoring weights for various HTML tags, used by the search engine. For example, <H1> tags currently have a high weight, of 25; a savvy site admin could give <H1> tags either greater or lessor importance by changing these values in the database or in settings.php. This variable has been around for some time. And while I see no harm in it, I'm unaware of anyone who uses this; and further, with the #145242: refactor search node_rank with hook_node_rank scoring factors allowing other scoring factors, I don't see this getting much use.
Comment #3
jvandyk CreditAttribution: jvandyk commentedBecause of the nature of actions, there is a possibility that you might have an action that calls an action that calls an action that calls an action...and you might get into an infinite loop.
actions_do() tracks the number of recursive calls to itself in the $stack variable, which is incremented at the beginning of actions_do() and decremented at the end of actions_do(). So if you have $stack going up and up, it may mean danger.
$actions_max_stack is the highest number of recursive calls to actions_do() that will be allowed before Drupal decides that infinite recursion is taking place and aborts. The default value for $actions_max_stack is 35. If $actions_max_stack is exceeded, Drupal will abort and write the following watchdog entry:
Stack overflow: too many calls to actions_do(). Aborting to prevent infinite recursion.
Comment #4
jvandyk CreditAttribution: jvandyk commentedBy default, Drupal keeps track of user access time using the access field of the users table. That is, at the end of a request, Drupal updates the current user's access field with a current timestamp.
The problem is that on a high-traffic Drupal site, the users table gets very busy. A horde of requests are being completed so lots of updates to the users table need to happen. But at the same time, at the beginning of each request the users table is being joined to the sessions table, so the users table needs to be used then, too. Thus access to the users table becomes a bottleneck.
One way to avoid the bottleneck is to do updates to the access field of the users table less often. That is what $session_write_interval does. By default it is 180 seconds. That means "if fewer than 180 seconds have elapsed since this user's last visit, skip the updating of the access field of the users table."
If you absolutely must track a user's exact access time, you can set this to 0 and the writes will always happen.
Comment #5
drewish CreditAttribution: drewish commentedmime_extension_mapping is used by file_get_mimetype() to allow for sites to have alternate extension => mime type mappings.
Comment #6
Bojhan CreditAttribution: Bojhan commentedThanks, tracking as well.
Comment #7
alex_b CreditAttribution: alex_b commentedYou can remove aggregator_allowed_html_tags from the list. A past patch accidentally removed the form for it, I've created an issue: #486246: Bring back form for aggregator_allowed_html_tags
Comment #8
sunTagging for feature freeze.
Comment #9
lilou CreditAttribution: lilou commentedSee also : #620650: Create a variables.php for documenting hidden variables
Comment #10
lilou CreditAttribution: lilou commentedMark as duplicate #672228: Document all D7 variables
Comment #11
lilou CreditAttribution: lilou commentedTag
Comment #12
webchickMarked #620650: Create a variables.php for documenting hidden variables a duplicate.
We have a globals.php for documenting global variables. A variables.php would make sense alongside it.
Comment #13
dawehnerMost of the variables can be associated with a certain core module.
What about a new group variables in the .api.php files?
Comment #14
SpleshkaSpent some time and get list of non-UI variables. Suppose we can now add it to documentation, what do you think?
Comment #15
andypostSuppose current branch is 8
Comment #16
Spleshka@andypost,
This variables are for 7.x.
Comment #17
chegor CreditAttribution: chegor as a volunteer commented7-years ping :)