July 2009 - Development - lists.drupal.org

File Storage and Path Display
by Bushidodeep 22 Jul '09

22 Jul '09

Hi, I've created a directory (i) inside the sites->default->files->i, upon a:hover, the path appears in the status bar. Is this customary or have I forgotten a setting in one of the path modules? CK

1 0

Files table includes file_directory_path
by Bevan Rudge 20 Jul '09

20 Jul '09

> Date: Wed, 15 Jul 2009 17:09:21 +0200 > From: Clemens Tolboom <clemens(a)build2be.nl> > Subject: [development] Why is the Drupal File System relative to > website root and not relative to admin/settings/file-system path? > > Having a development test acceptance and production environment it's a > drag when moving the production database and files to an acceptance or > development environment. > > One has to update the files database table and more tables or do > trickery with symlinks to get the site running clean. > > If we could make the filepath in the files table relative to > the /admin/settings/file-system path the real files are relocatable > without pain. Just do a db load and a rsync to get the files and change > the dmin/settings/file-system path. > > What do you think? Did I miss something important? There is a featurebug in Drupal core that has been around since Drupal 5 or before, where the file API allows modules to save and retrieve files using a path relative to either the Drupal root or variable_get('file_directory_path', ...). A number of people have tried to fix this (including myself) in Drupal core, but it is a rather overwhelming issue since so much code in core and contrib now expects not only the file API, but also the files table to include variable_get('file_directory_path', ...). Attempts to fix it in the past sometimes gets distracted by related issues such as sites/sites.php and default files_directory_path, which don't actually solve the featurebug. At CivicActions we have a tool (pushdb --xFix) that fixes the paths in the files directory and elsewhere in the db, which we run when copying an instance of the site to a staging environment. However this approach is becoming unsustainable and we are considering using a separate instances of Drupal core in each and every staging environment so that they all use sites/default. What this means is that much of the time this featurebug is such a PITA that Drupal's multisite features don't work for staging environments. In my own sandbox I don't use multisite for staging environments at all, because of this issue, Do others? > Message: 6 > Date: Wed, 15 Jul 2009 19:02:38 +0300 > From: ufuk bayburt <ufukbay(a)gmail.com> > Subject: Re: [development] Why is the Drupal File System relative to > website root and not relative to admin/settings/file-system path? > > See http://drupal.org/node/366464. That's the cleanest fix for this bug I've seen yet, but still seems to have wider ramifications than that patch fixes, and that's just Drupal core. I think it also needs an update handler that fixes paths in the files table for Drupal 6 sites upgrading to Drupal 7. > Date: Wed, 15 Jul 2009 11:08:44 -0500 > From: James Gilliland <neclimdul(a)gmail.com> > Subject: Re: [development] Why is the Drupal File System relative to > website root and not relative to admin/settings/file-system path? > > Set up your production filesystem path first and set that before > developing your site? You misunderstood the initial post. The poster is asking about the case where he/she creates a staging environment from the live environment, not the other way around. However you've raised another issue derived from this featurebug. If you are developing a site on a domain which will not be the final domain name (e.g. because the site you're developing is replacing a non-drupal site), and your conf_path() is not sites/default, then you need to set your files_directory_path beforehand and/or create a system of symlinks to workaround the featurebug (or be screwed if your on windows). The foresight usually come with the experience of having been burned by this featurebug – probably when you deployed a site and all the files broke a previous time. This hurts the developer experience. > Date: Wed, 15 Jul 2009 12:39:17 -0400 > From: Moshe Weitzman <weitzman(a)tejasa.com> > Subject: Re: [development] Why is the Drupal File System relative to > website root and not relative to admin/settings/file-system path? > > fixed in d7 with sites/sites.php. you can map one path to another so > the that two environments can be made to look the same. see > http://api.drupal.org/api/function/conf_path/7. > > of course d6 still needs some tricks. While that's a great feature it doesn't fix this featurebug, it just provides another workaround for when it breaks and for those with foresight. Bevan/

9 10

lightbox2 - co-maintainer needed!
by Stella Power 20 Jul '09

20 Jul '09

Hi all, The lightbox2 <http://drupal.org/project/lightbox2> module's issue queue is just getting too large and busy for me to cope with all by myself. It's becoming increasingly difficult to keep on top of the issues as I just don't have as many free hours as I used to to devote to it. So I'm looking for a co-maintainer :) You don't need to be a PHP or JavaScript whiz - though if you are, great! Experience with jQuery and Firebug would help, however as long as you have some time to help out with the issue queue by investigating support issues, etc, then send me a mail. Cheers, Stella

2 2

Weather module
by Aldo Reset 20 Jul '09

20 Jul '09

hi, i notice a little bug in weather module. i think you must change   by   that is an unbrekable space. bst regards.

2 1

rfc compliant
by Aldo Reset 20 Jul '09

20 Jul '09

does core drupal for some field will be rfc compliant ? mail address: varchar(320) any domain name field: varchar(255). bst regards

2 1

How to disable any block or sidebar from module
by Tomáš Fülöpp (vacilando.org) 18 Jul '09

18 Jul '09

Hi, I cannot find a generic way how to disable a sidebar programmatically. In my module, if some conditions are met, I would like to make sure that the whole sidebar (or any blocks in it) are not rendered at all, regardless of the theme. Could somebody advise, please? Sorry if it's obvious.. Thanks, *vacilando* -- Tomáš J. Fülöpp http://www.vacilando.org

6 6

Re: [development] Files table includes file_directory_path
by Khalid Baheyeldin 17 Jul '09

17 Jul '09

On Thu, Jul 16, 2009 at 10:50 AM, Adrian Rossouw <adrian(a)daemon.co.za>wrote: > > On 16 Jul 2009, at 4:16 PM, Khalid Baheyeldin wrote: > > As others said, you either use symlinks (which forces you to have two >> directories per site), or the new sites.php feature of Drupal 7. >> >> Using that, you can have a contrived name for each site (even site1, >> site2, or an md5 hash for each site), and redirect the site in it. >> >> The trick is to not use sites/default for each site from now on, and only >> use a unique identifier. That identifier can be the same when you develop >> the site, and remains the same when you deploy the site. >> > > Just because a work around exists doesn't mean the current behaviour isn't > wrong. > > What are the reasons for the files not being relative ? > Relative or absolute can be debated. I think that relative is more elegant and more portable. But this is for stuff in the files table only. Once you publish a site and you reference static things in it as <img src="/sites/ site1.example.com/files/blah.jpg" /> you are stuck with that path. The sites.php method avoids this. You can have sites/12345/files/blah.jpg, and it is no longer dependent on the domain name. Development and testing can happen to the same path. So, yes, I agree that relative is better, but it does not solve all the issues that sites.php does. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci

1 0

problem with custom date and timezones
by Lluís 17 Jul '09

17 Jul '09

I have created a custom node type. I have a date field which I created as int in order to use it in views, being able to sort it, format, etc.... My problem right now is that when inserting a node with one date, it appears as "day before" when viewing the node. How should I save it to avoid this problem? My form looks like $arrayF=getdate(($node->data_paper>0 ? $node->data_paper : time())); $arrayF['month']=$arrayF['mon']; $arrayF['day']=$arrayF['mday']; $form['data_paper_array'] = array( '#type' => 'date', '#title' => 'Data Factura', '#default_value' => $arrayF, '#required' => TRUE, '#weight' => -9, ); My insert query looks like $dateF=$node->data_paper_array; $factura_tmsp=mktime(0,0,0,$dateF['month'],$dateF['day'],$dateF['year']);// $date['year']."-".$date['month']."-".$date['day']; $node->data_paper=$factura_tmsp; db_query("INSERT ......); And my theme function: $output.="<li><b>Data Factura:</b> ".format_date($node->data_paper,'small')."</li>"; Any hint/advice? Thanks -- *La vida és com una taronja, què esperes a exprimir-la? *Si creus que l'educació és cara, prova la ignorància. *La vida és com una moneda, la pots gastar en el que vulguis però només una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

3 5

Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path?
by Clemens Tolboom 17 Jul '09

17 Jul '09

Having a development test acceptance and production environment it's a drag when moving the production database and files to an acceptance or development environment. One has to update the files database table and more tables or do trickery with symlinks to get the site running clean. If we could make the filepath in the files table relative to the /admin/settings/file-system path the real files are relocatable without pain. Just do a db load and a rsync to get the files and change the dmin/settings/file-system path. What do you think? Did I miss something important?

10 11

Re: [development] Why is the Drupal File System relative to website root and not relative to admin/settings/file-system path? (Action Required)
by postmaster＠boxbe.com 16 Jul '09

16 Jul '09

Hello ufuk bayburt, This message serves as notification that you will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority queue for our member to review at their leisure. Future messages will be more likely to be viewed if you are on our member's priority Guest List. Thank you, bharanikumariyerphp(a)gmail.com About Boxbe This courtesy notice is part of a free service to make email more reliable and useful. Boxbe (http://www.boxbe.com) uses your existing social network and that of your friends to keep your inbox clean and make sure you receive email from people who matter to you. Boxbe: Say Goodbye to Email Overload Visit http://www.boxbe.com/how-it-works?tc=229711722_1448946350

1 0