- Development - lists.drupal.org

Short issue queues need care
by Augustin (a.k.a. Beginner) 18 Jun '06

18 Jun '06

Pick your list: 1) 4.7 patch queue: http://drupal.org/project/issues?projects=3060&states=8,13,14&versions=10696 7 issues only (4 over two weeks old). 2) pre-4.7 betas issues: http://drupal.org/project/issues?projects=3060&versions=10634%2C10412%2C103… 8 issues only. 3) cvs critical bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 3 issues only (2 over two weeks old). 4) cvs patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 58 issues only (53 over two weeks old) :) 5) cvs base system patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&components=bas… 7 issues only (4 over two weeks old). 6) cvs node system patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&components=nod… 4 issues only (all over two weeks old). 7) cvs user system patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&components=use… 2 issues only (it's a bargain!) (both over two weeks old) 8) cvs theme system patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&components=the… 2 issues only (another bargain!) (both over two weeks old) 9) cvs database system patches need review: http://drupal.org/project/issues?projects=3060&versions=6487&components=dat… 2 issues (third bargain) (both over two weeks old) 10) urlfilter issues: http://drupal.org/project/issues/urlfilter 10 issues only (7 over two weeks old). ... but no one can commit any patch: http://drupal.org/node/65116 So, which one do you choose? What other short issue queues should be promoted and cared for? Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

1 1

hook_onload?
by Tim Jones 18 Jun '06

18 Jun '06

Has hook_onload been deprecated in 4.7? This page says implies it has, http://drupal.org/node/22218#hook_onload But his page says it has not, http://api.drupal.org/api/4.7/function/hook_onload Am I missing something, or should we clean up the documentation? Thanks, =T= tjones.cc / toneland.net

2 1

Re: [development] Staging content to production
by Scott Reynolds 17 Jun '06

17 Jun '06

ok...but what happens when your user base excedes 1000. What would happen to your staging area? How would you assign a unique uid > 1000? How about when your vocab excedes 1000. This is a VERY VERY VERY bad software design move. Scott Dave Cohen wrote: > I've started to address this issue by reserving the first 1000 ids for the > "staging" (or if you prefer, "install profile"). So for instance node nid 10 > comes from the install profile, while node nid 1010 is on the production > server only. Same goes for vocabulary with vid 10 (or 1010), menu with mid > 10 (or 1010), etc. Later, I can add node 11 to the install profile and > propigate it to my production site easily enough and without fear of > overwriting anything that's been configured on the production server. > > You can read exactly how I do this here <http://dave-cohen.com/node/1066>. > wow, thats a very clever solution to the problem. i would totally support > drupal patches which insure that ids start at 1000. i'm not so sure about a > patch which adds unique keys to all tables. we need someone db person to > chime in there. anyway, it would be handy if we supported this trick better > (i.e. without patching). thanks for sharing. -moshe

2 1

drupal vs. free hosting action points
by Gabor Hojtsy 17 Jun '06

17 Jun '06

Hi, Since there is a significant interest in the Hungarian Drupal user crowd to use Drupal on several of the free hosting accounts provided in our country, and there were quite a few problems before, I decided to look into installing Drupal on the two major free hosting services (ultraweb.hu and freeweb.hu). Here are my observations on supporting free hosting providers (it was not straightforward, nor easy for a beginner). 1. Everything is under the webroot. You can put nothing out of the webroot folder. This makes you lose the private files feature, and forces you to set up an upload temp folder under the webroot. Fortunately Drupal tries to suggest a folder under the files folder, so the temp folder is also (supposed to be) protected from malicios PHP files, if .htaccess would be supported. => Nothing to do here, just a fact. 2. Htaccess files are not allowed. At least you are prevented from uploading them via FTP. You can create them with PHP (the .htaccess in the files folder is created), but then the contents does not matter. I bet they have AllowOverride None set. => Implication: Clean URLs are unusable, PHP settings are not set as ideally expected by Drupal. Fortunately Drupal is capable to work even in these harsh conditions, given the code to programatically turn off magic_quotes for example. But there are security problems, since the .module, .theme, .install, etc files are not protected. Only phptemplate theme files are protected because of their free hosting friendly .tpl.php extension usage. Action point: maybe we should revisit using .module.php, .theme.php, .install.php etc file extensions Action point: look around what is affected if the expected PHP settings are not there 3. Some of the PHP functions are disabled, so the screen is full of errors, instead of Drupal working right. The affected functions on the two hosts are: - ini_set (in settings.php) => nothing set with this is effective (even where this is enabled, the settings are set with php_admin_value in Apache, so we cannot override several settings) - mkdir(), chmod() (in the files and temp folder setup) => cannot create the folder and/or chmod() them to the right permission - realpath() (used in files related code) Action point: wrap the ini_set() call into a disabled_functions check Action point: replace realpath() with drupal_realpath() and use a less secure but at least somewhat working alternative if realpath() is not available (see http://php.net/realpath user notes) Action point: think about making the mkdir and chmod calls conditional too Action point: provide a compatibility summary page, where the existing GD, clean URL and other stuff is moved to, plus PHP settings and other stuff is checked for and displayed => one knows how secure or capable his system is by visiting this page (Q: how is this affected by the install system?) 4. Because of some restrictions on the runtime of PHP scripts, it is not surely possible to import the Hungarian translation in complete. Some of our users manually split the po file into six or more chunks (with po headers added to all chunks), and import these one-by-one manually. This is ehm, quite lame to suggest... What seems to be a solution is to get back to SQL imports for languages, at least for supporting these restricted hosts. This has other advantages of setting up language specific parameters (while we are waiting for an installation profile system :). Action point: investigate providing translations as SQL dumps additionaly to PO files By the way our free hosting services are not employing any of the CPanel, Plesk or other web admin software. They all developed their own home-grown solutions, so the limitations, setup screens are all different (and sometimes quite confusing even for experienced people like me). Mail sending has its different tricks on different hosts, some have nice daily cron support, some have no cron support. All use phpmyadmin though, so this is the common starting point. I would suggested we first discuss these action points, and then find people to implement those desired. Gabor

3 3

Re: [development] Re: [consulting] Module to view/edit module weights
by Khalid B 17 Jun '06

17 Jun '06

> > Remember that a mechanism similar to weights is used in UNIX/Linux > > init scripts (each daemon is given a 3 digit number and they are started > > in order). > > How many people actually use that? I've never even seen such a 3 digit > number in Gentoo. (I believe there is a dependency system or something, > I don't ever need to look at it.) All UNIX like systems that use the sysvinit (System V Initialization) use this. This is on UNIX V.4, Solaris, Red Hat, Mandriva, Ubuntu ...etc. # cd /etc/rc3.d/ # ls S10sysklogd S19mysql-ndb-mgm S20mysql S20ssh S25mdadm S89cron S99rc.local S11klogd S20makedev S20postfix S21mysql-ndb S50proftpd S91apache2 S99rmnologin These are just symlinks to the real script that does the start and stop which is in /etc/init.d/ for each service. > > This is similar to update-rc.d in Debian/Ubuntu. > > Never used it, I'm going to guess a majority of Drupal administrators > haven't either. That does not mean it is not there, just that you did not come across it. On Debian/Ubuntu, it is the update-rc.d that does it. http://wiki.linuxquestions.org/wiki/Update-rc.d On Redhat and family there is chkconfig. http://www.netadmintools.com/art94.html There is always the manual way as well: ln -s /etc/init.d/somedaemon /etc/rc3.d/S42somedaemon I am not saying this is the best or worst way, but the concept is used elsewhere.

2 2

Overiding #theme in hook_form_alter()
by Barry Jaspan 16 Jun '06

16 Jun '06

I've written the module that wants to override the #theme of another module's form. I discovered that in hook_form_alter I cannot set the #theme field because drupal_get_form overrides #theme after calling hook_form_alter it if the function theme_<formname> exists or the $callback argument is provided. This seems like an unintentional restriction to me. Is it? Hook_form_alter can change everything else about a form, so why should it not be able to change the #theme field? I know the theme function can be overridden by the site theme but that forces the module not to be self-contained. The workaround I found is to add a callback to the form's #pre_render array that sets the form's #theme field. This works fine (because #pre_render is invoked after drupal_get_form overrides #theme) but is certainly not intuitive; if this really is the best way to do it, I'll author a new page for the Forms API Tips and Tricks book section. Thanks, Barry Note: This message was dictated using voice recognition software. Please excuse any errors I missed.

2 2

losing value somewhere after validate.
by sime 16 Jun '06

16 Jun '06

Hello. I keep losing values that I modify in the 'validate' op of hook_nodeapi(). This occurs by the time I get to the insert or update ops. It has to be something simple I am overlooking. I normally wouldn't hassle the list over such things, but I am starting to write bad code to compensate, so I need to work out what I'm doing wrong. It is a little hard for me to track the $node through core, so are there any suggestions about what I might be doing wrong, or where a problem like this can arise? Kind thanks for any advice. Simon PS. I have checked the nodeapi docs: "validate": The user has just finished editing the node and is trying to preview or submit it. This hook can be used to check or *even modify the node*. Also, I have double-checked that i am using a version of form.inc that is after this issue was fixed: http://drupal.org/node/63704

3 3

Module to view/edit module weights
by Barry Jaspan 16 Jun '06

16 Jun '06

[ I posted this to the consulting list but since discussion has already arrived here I figured I should re-post the original message. FYI, this is what caused me to discover the problem with #theme and hook_form_alter. ] A client needed to be able to change the weight of a module I developed for him. Rather than hard code the setting in the module's .install file, I developed a small module called moduleweight that adds a Weight column to the modules table at admin/modules. I was not aware of any existing way to do this. Module moduleweight is available in CVS. If other people find it useful, I will promote it to a 4.7 project. Thanks, Barry Note: This message was dictated using voice recognition software. Please excuse any errors I missed.

1 0

Re: [consulting] Module to view/edit module weights
by Khalid B 16 Jun '06

16 Jun '06

(Cross posting to development) There was criticism about weights in the past (I think it was Ber?) However, I think the lack of an interface to manipulate the underlying data structure was the main objection to this. Remember that a mechanism similar to weights is used in UNIX/Linux init scripts (each daemon is given a 3 digit number and they are started in order). Now that we have an interface that can manipulate the weights, perhaps the main criticism is moot. This is similar to update-rc.d in Debian/Ubuntu. But perhaps we will move to a before/after scheme as hinted to (Adrian? Vlado?)

2 1

Re: [development] Test automation
by Khalid B 16 Jun '06

16 Jun '06

Just an aside here whichever way it gets done ... The potential for abuse here is very high. Someone may craft a patch that executes arbitrary PHP code that can be effectively anything. Having a virtual server to do this will help with some scenarios, but others (e.g. sending spam, crawling, phishing) can still be useful to the cracker ...

2 1