- Development - lists.drupal.org

[User experience feature] Variable overrides in settings.php
by drlingo 17 Dec '06

17 Dec '06

Issue status update for http://drupal.org/node/38713 Post a follow up: http://drupal.org/project/comments/add/38713 Project: User experience Version: <none> Component: usability Category: feature requests Priority: normal Assigned to: Zen Reported by: Zen Updated by: drlingo Status: patch (code needs review) I have tried to use your patch however, I receive a blank screen when I installed the patch. What must I do to make this work? This problem with the online, offline function needs to be resolved I know I can't be the only one. drlingo Previous comments: ------------------------------------------------------------------------ Thu, 24 Nov 2005 05:56:03 +0000 : Zen Hi, When a user moves/duplicates a site with clean_urls on, caching etc. he is very frequently locked out if he can't get mod_rewrite etc. working. Similarly, with the new Site Offline/Online feature, there doesn't seem to be any option for the admin to turn it off or log back in if he accidentally logs out.. The site/default/settings.php file has a section that allows overriding these DB variables. If the above mentioned variables can be added (and commented out), it might make things a lot easier to rescue the site without having to mess around with serialized variables in the variables table.. <?php $conf = array( 'site_name' => 'My Drupal site', 'clean_url' => 0, 'clean_url_ok' => 0, 'cache' => 0, 'site_offline' => '0', ); ?> (I'm not entirely sure what clean_url_ok does, but I've added it in anyways..) If and when all the variables to be added are decided, I'll attach a patch file. Cheers Karthik. P.S User Experience/usability seemed like the best place to put this.. ------------------------------------------------------------------------ Thu, 24 Nov 2005 19:54:08 +0000 : Geary This is an outstanding idea! I have been in this fix myself, and naturally looked in settings.php to see if there was an override. Having these "safe mode" settings visible and commented out would save a lot of people a lot of headache. ------------------------------------------------------------------------ Thu, 24 Nov 2005 23:15:21 +0000 : lekei In my settings.php I have the ability to launch the site in safe mode: /* * Safe mode -- launch site with safe settings */ if ($ALLOW_SAFE_SETTINGS && isset($_GET['SAFE_SETTINGS'])) { $conf = array_merge( $conf,array( 'site_name' => trim($_SERVER['HTTP_HOST'],"/").' (SAFE MODE)', 'theme_default' => 'pushbutton', 'clean_url' => 0, 'cache' => 0, 'site_offline' => '0' )); } at the beginning of settings.php there is a line allowing disabling safe mode: // Permits launching the site in "safe mode" by acccesing it with: // http://yourdomain?SAFE_SETTINGS $ALLOW_SAFE_SETTINGS = TRUE; ------------------------------------------------------------------------ Fri, 25 Nov 2005 03:37:25 +0000 : Zen @lekei: ah, that's a lot cleaner. But I assume that you're either using Civic or have added this in yourself? It isn't present in standard installations. I'm not sure the _GET is really required though. Either way, you should make that into a patch and submit it. Cheers Karthik. ------------------------------------------------------------------------ Sat, 14 Jan 2006 22:56:33 +0000 : Zen Attachment: http://drupal.org/files/issues/settings_5.patch (579 bytes) Patch attached. -K

1 0

(no subject)
by Chad Phillips -- Apartment Lines 16 Dec '06

16 Dec '06

snip from Kjartan's post... "Originally the Sandbox was created as a place to put core patches that were pending review, as we did not have any issue tracker back then. Since then the project module has grown and can now cover most of the original purpose of the sandboxes" snip from Gerhard's post... "The rules haven't changed, they are only enforced." is there some reason we need to shoot ourselves in the foot by blindly applying an existing policy? let's look at a few things here: 1. The sandbox had an original purpose, and the sandbox resource was created 2. The original purpose is outdated 3. People have found other good uses for the resource so the policy for the sandbox is outdated, right? how about we take a little time to update the policy by discussing it here?? it's clear to me that in the intervening time, the community has used it's resourcefullness to find other good uses for the resource -- i think we should try to benefit from that. i see no reason to limit the sandbox to only giant core patches. the resource has obviously proven useful as a place to store pre-alpha contrib work -- there are already people who have spoken out on that. based on the statistics that Frando published, we're certainly not experiencing a resource problem. i'm in favor of a rule more like Karoly suggested: "sandboxes are to be used for code that benefits the Drupal community". can we give a shot at turning that into an updated policy?? hunmonk

1 0

Could be interesting ...
by Dries Buytaert 15 Dec '06

15 Dec '06

Could be interesting ... http://www.alledia.com/blog/seo_competition/ joomla_v._wordpress_v._drupal/ ... and maybe a good time to double check the SEO-ity of Drupal 5. ;) -- Dries Buytaert :: http://www.buytaert.net/

8 7

Drupal 5.0 RC 1 released
by Dries Buytaert 15 Dec '06

15 Dec '06

Hello world, as you might have noticed, we released Drupal 5.0 RC 1 today. Congrats and kudos for all the hard work. Good job, folks! -- Dries Buytaert :: http://www.buytaert.net/

1 0

Re: [development] Rename hook_menu ?
by Darren Oh 15 Dec '06

15 Dec '06

Seems to me that each menu item is actually a page, which may or may not appear in the menu. So I would suggest hook_page.

1 0

OT: PHP security team changes
by Khalid B 14 Dec '06

14 Dec '06

Just an FYI Stefan Esser leaves the PHP security team. http://www.heise-security.co.uk/news/82500 http://developers.slashdot.org/article.pl?sid=06/12/14/0410240

2 2

Rename hook_menu ?
by Karoly Negyesi 14 Dec '06

14 Dec '06

Today it was raised in #drupal that hook_menu has so little to do with menus nowadays that hook_control is likely to be a better name for the system. Thoughts are welcome. MVC flames are not. Regards NK

24 27

Preparing for 5.0 string freeze
by Angela Byron 13 Dec '06

13 Dec '06

I know it has not traditionally been something we've done, but I'd really like to do a string freeze @ RC1 if we can possibly help it. For those who don't know the term, a "string freeze" means "everything that's in a t() can't be changed from this point out" unless it's to fix a 'critical' bug; for example, instructions that tell you to click something that isn't actually there. This makes it possible for translators to start kicking into high gear and translating Drupal 5 at the RC phase, so by the time 5.0 is released we have a plethora of options to choose from. So in preparation of this, we need to do the following: a) A large patch, or series of patches, which "clean up" translated strings; stuff like getting rid of \' and change t('<p>blah...') to '<p>'. t('blah...') and such. Which would be best? One patch per file, or a large one that just makes these minor changes everywhere? b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear. c) An answer to question posted @ http://drupal.org/node/92992: Should we remove the "You can" links from module help? And if the answer's "yes", then patches to make that happen. (my personal vote is for "yes" since those bloody links were the bane of my existence when I was writing those help handbook2helptext scripts back in the day). Also, anyone have a sense whether the next release of HEAD that's rolled will be another beta release or whether it will be a release candidate? I'd love to get an approximation of how much time I have to work on these issues (and also if anyone's interested in helping). -Angie

9 13

Re: [development] Rename hook_menu ?
by Metzler, David 12 Dec '06

12 Dec '06

I agree. We are basically defining the entry points and access control to the appliction. Yes, it's more than a menu, but I don't find it to be fully fledged "controller" either. And calling it a controller sort of hints incorrectly at that it does more than you'd think. In short, I don't find the use of menu innapropriate enough or feel that the other replacement terms communicate more to a new developer. Menu is close enough. Dave ________________________________ From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Zohar Stolar Sent: Tuesday, December 12, 2006 3:34 AM To: development(a)drupal.org Subject: Re: [development] Rename hook_menu ? It's true, but hook_menu is, after all, dealing with paths and links. Paths and links are what allows us to navigate inside a site, and they are commonly combined in a menu. If we checked it statistically, I'm sure we would have found that most of the items in the menu hook are not actually visible as menu items, but when thinking of a menu i a larger context, we find it's not at all a bad name. A menu is a representation of a site's structure, whether it's a logical structure, or a more physic one. So in this way - even if an item is not visible, it's still part of the structure, and as a result - has its place in the menu. Zohar Karoly Negyesi wrote: Today it was raised in #drupal that hook_menu has so little to do with menus nowadays that hook_control is likely to be a better name for the system. Thoughts are welcome. MVC flames are not. Regards NK

1 0

another new status: "active (needs more info)"
by Derek Wright 11 Dec '06

11 Dec '06

looking at an issue where the person who reported it supplied so little information, you have no idea what they're actually talking about, how to reproduce the bug, etc? you can now set it to "active (needs more info)". the reporting user will have to reply and set the status back to "active" if they want their issue to be seen again (as a new status value, this won't appear in the default issue listings unless you specifically query for issues in this state). see http://drupal.org/node/102485 for background/discussion. cheers, -derek p.s. yes, this too should be documented in the handbook, along with the "patch (needs porting)" status. any volunteers?

1 0