support October 2012

support@drupal.org

59 participants
68 discussions

Re: [support] localization
by Mark Grieveson 30 Oct '12

30 Oct '12

On Tue, 30 Oct 2012 16:42:38 +0000 support-request(a)drupal.org wrote: > Have you looked at http://localize.drupal.org/translate > > > Nancy Hello Nancy. Yes, I have. From that page, I searched for en-GB, and it directed me to http://localize.drupal.org/translate/languages/en-gb This, however, is the old localization file that does not work on the current Drupal. Both WordPress and Joomla have en-GB localization for their current releases, so I'm not completely out of luck. Mark

1 0

Re: [support] localization
by Mark Grieveson 30 Oct '12

30 Oct '12

> I would strongly suggest you try Drupal 7, or even Drupal 6 if you > must. Drupal 5 is no longer supported with any maintenance updates. > > -Benj Hello Benj. Thanks for your response. I am using Drupal 7, specifically version 7.16. It reports that everything is up-to-date. But, it seems the only version of the en-GB localization is a file that was intended for Drupal 5.20. So, I guess I'm out of luck. Ah well, I think either WordPress or Joomla have support for en-GB localization. Mark

2 1

Re: [support] Site Hacked
by Roger 30 Oct '12

30 Oct '12

My apologies for top posting but as this whole post is quite long, a response at the bottom could be lost. Thank you Earnie. Some of the below is most informative, it opens viewpoints that I did not know about. I have been looking at Ruby on Rails and it seems that dev/test/deploy are built in, and configurable. Deployed site does not have admin privileges, it's just a display - user input mechanism, at least this is my understanding. Code modifications are inserted, for want of a better word, with Git. Whether this is good or not I am yet to explore, but it does seem to be along the lines of what I attempt to propose below. Mind you, there are significant problems with RoR. One such is that if there is a Ruby or Rails engine update, the site will probably break, so it's not the be all and end all, but the dev/test/deploy seems robust. Another is the complex setup requirements, both of which Drupal has overcome. Unfortunately for us, some modules are just that, workarounds. Take NAT for instance, not necessary in our system but needed, for now, to overcome an interplay problem between Workbench and Taxonomy. Lockout is built into Drupal. <snip> So use the alter hooks to add another field.</snip> I would really like to understand how to do this, it may solve a number of issues. So it is with settings.php and sites.php, I have only basic understanding of these. Cheers >>> Pl go to drupal support and give your details and report them about >>> hacking better change admin password >> No point in doing that. It's a whole of Drupal design thing, >> including engine and modules. It is not a small problem. The inherent >> problems, for us, with Drupal 7 are: - The engine is part of the site >> and can be played with/altered while live. Convenient but potentially >> damaging. > Not if you give the correct permissions on the files. >> - There is no way to not have admin on a live site. In fact there >> should be no admin at all on a live site or as a minimum, a disabling >> switch. Without admin access a live site is less vulnerable. It can >> be hidden but not disabled. > Impossible. You always must have an administrator to get the site > configuration correct and to run updates. >> Live should be just display of data with limited data input and >> change thereof. This requires another mindset for Drupal as a whole. > That depends on the nature of the site. If you don't want to have > users inputting data then don't allow the data to be input. That is > done via the permissions the administrator would set up. Drupal is > designed more to present dynamic data and not static but that doesn't > mean the dynamic data cannot be static, it surely can. In fact those > sites that use Drupal for the dynamic data also have static data that > is displayed. >> - For us, some components, that we needed, like say Work bench, >> taxonomy, and several others need admin permissions for the user to >> enter/change data. This opens a pandora's box of risk. > Do they need "admin permissions" or just "permissions"? Drupal is > designed to allow the site development to provide hooks to modify the > workflow of the system. You can even add permissions that are not > available by default. This is done via alter hook implementations that > modify the form data and even the form submission routines. >> Alternatively we write work around code or find and install yet >> another set of "work around" modules to overcome the problem. This in >> turn introduces potential threats, risks, more maintenance, etc. To >> date we have several work around modules. > I wouldn't call any module a "work around", it is the way Drupal works > to provide flexibility to the design. If you use the Drupal set of > standards for coding then you should not have introduced potential > threats but of course there is always the possibility. >> Creating modules or rewriting is not an option for me. I do not like >> PHP, it's boring, cumbersome and repetitive. > Then hire someone who likes it. There are many. >> - Configurations are stored in the database, there is no way to dev >> or test without entirely separate installs which require copies of >> the live database updated into the dev/test areas. We can't work on >> updated data without potentially wrecking d/t changes and vice versa. > Drupal 7 has the thing called sites/sites.php which can map a site to > the configuration data and can be used to map 'dev.example.com' to > 'example.com/settings.php'. Settings.php can also be used to create > the configuration data. If the data required is already mapped in the > global variable $conf then it will not be pulled from the DB. E.G. > sites/sites.php $sites['dev.example.com'] = 'example.com'; >> Ideally configurations could be separate from data. Dev/test could >> instead be a subset of live data with just the config and display >> changes worked upon. We don't have the expertise to go through every >> table to find which is linked to which. > There are contrib modules created to help with this. You'll be excited > to know that configuration management improvement is one of the goals > for D8. >> - There is no clean, obvious way to move a small change from dev/test >> to live site without overwriting the database or part thereof which >> means that latest data may be changed or some field content no longer >> relates to changes. Unless yet another set of protocols is introduced >> with more complication. > Modifying the database always requires the site be in maintenance > mode. Development cycles that code for 3 or 4 months then deploy > always require coordination especially when the database data is > involved. However, this is normal workflow and nothing new nor unique > to Drupal. It is expected to have to manage the production deployment > in such a manner as to not break the production site and to deploy in > as fast as possible haste to minimize the downtime. There are contrib > modules to help with moving the configuration from development to > production. They do not need to remain active during production mode. >> - Introducing changes as above, for us, have wrecked parts of the >> live system because it seems, virtually every table is referred to by >> every other table in some way. > What tables would you be changing? Yes the data dependencies are > interwoven between tables; again nothing unique to Drupal but is > standard database construction. >> - When Admin, on a static IP, is locked out there is no way, apart >> from waiting many hours, for the ip lockout to be dropped. Unless >> there are 2 or 3 admins and one or those resets the lockout, not easy! > Is this Drupal related or site host management related? You might need > to take a look at the banned sites file in the /etc folder and add an > IP address to the allowed sites file in the /etc folder. >> - We routinely use extremely convoluted very long passwords, changed >> regularly. The password is the only hidden part of a log in. User >> names are displayed to all and sundry. For us, hiding actual user >> names and displaying preferred user names unrelated to login would be >> more secure. > The authentication can be modified and can be configured to be > something else besides the standard authentication. It might require > PHP coding or understanding of authentication configuration. >> Barriers to hacking Drupal core are the password and the 5 tries and >> you're out. Hidden user name and display of preferred, but different >> name could add another level of security. > So use the alter hooks to add another field. You can do it even though > you hate to code in PHP because it's boring.

2 1

localization
by Mark Grieveson 30 Oct '12

30 Oct '12

Hello. I have installed drupal successfully on a localhost running Vector Linux (similar to Slackware). I use lighttpd. I installed a British language package, specifically drupal-5.20.en-gb.po, which I put in the profiles/standard/translations directory. This seemed to work during the installation, but all words are spelled with en-US (IE, "color"). Is there something else I need to do? I tried running various things in Home » Administration » Configuration » Regional and language (IE, the Translate interface), but this did nothing. All suggestions appreciated. Mark

3 2

Re: [support] Pager Query D7
by Earnie Boyd 30 Oct '12

30 Oct '12

Anything present in admin/reports/dblog? The theme function itself can return an empty string. The theme_pager function though, if called, doesn't give an empty string. You must use the setQueryCount() method to limit the query, also if one page or less of data is displayed no pager is output for it either. On Mon, Oct 29, 2012 at 2:20 PM, Ms. Nancy Wichmann <nan_wich(a)bellsouth.net>wrote: > I am not creating a form, so I have > $output .= theme('table', $table); > $output .= theme('pager'); > The table displays just fine. I have dumped the output of the pager > function and it is NULL. > > *Nancy* > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, Jr. > > ------------------------------ > *From:* Earnie Boyd <earnie(a)users.sourceforge.net> > *To:* support(a)drupal.org; Ms. Nancy Wichmann <nan_wich(a)bellsouth.net> > *Sent:* Monday, October 29, 2012 1:55 PM > *Subject:* Re: [support] Pager Query D7 > > Do you have something similar to > > $form['pager'] = array('#value' => theme('pager')) > > You may also need $query->setQueryCount() instead of the addExpression > http://api.drupal.org/api/drupal/includes%21pager.inc/function/PagerDefault… > > > On Mon, Oct 29, 2012 at 12:20 PM, Ms. Nancy Wichmann < > nan_wich(a)bellsouth.net> wrote: > > Thanks, Jamie. No difference. > $query = db_select('comment', > 'c')->extend('PagerDefault')->limit($limit)->extend('TableSort'); > $query->innerJoin('users', 'u', 'u.uid = c.uid'); > $query->addField('u', 'name'); > $query->addField('u', 'uid'); > $query->addExpression('COUNT(*)', 'number'); > $query->groupBy('c.uid'); > $query->range(0, $limit); > $query->orderByHeader($table['header']); > $result = $query->execute(); > I did look at node_admin_nodes() and don't see anything significant to > tell me why theme_pager() isn't working for me. [image: :(( crying] > > > *Nancy* > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, Jr. > > ------------------------------ > *From:* Jamie Holly <hovercrafter(a)earthlink.net> > *To:* support(a)drupal.org > *Sent:* Monday, October 29, 2012 12:01 PM > *Subject:* Re: [support] Pager Query D7 > > When using extenders, the position of the extender is important. Check > out: > > http://drupal.org/node/508796 > > So make sure you have the ->extend right after your select. Then use your > $query to do whatever other joins, conditions, fields, etc. you want. Put > the limit in on that too. > > You might want to check out node_admin_nodes() in node.admin.inc to get a > better idea. > > Jamie Hollyhttp://www.intoxination.net http://www.hollyit.net > > On 10/29/2012 11:49 AM, Ms. Nancy Wichmann wrote: > > I have a pager query ("$query = > $query->extend('PagerDefault')->limit($limit);") coded and it is working > fine. However, the theme('pager') is doing nothing. It returns a null > string, so I am not getting a pager on the page. I have searched all over > D.O, but am apparently missing the solution. > > *Nancy > * > > Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. > King, Jr. > > > > > -- > [ Drupal support list | http://lists.drupal.org/ ] > > > -- > [ Drupal support list | http://lists.drupal.org/ ] > > > > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > > -- Earnie -- https://sites.google.com/site/earnieboyd

2 2

Pager Query D7
by Ms. Nancy Wichmann 29 Oct '12

29 Oct '12

I have a pager query ("$query = $query->extend('PagerDefault')->limit($limit);") coded and it is working fine. However, the theme('pager') is doing nothing. It returns a null string, so I am not getting a pager on the page. I have searched all over D.O, but am apparently missing the solution. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

3 3

Drupal File Operations (D715)
by Austin Einter 29 Oct '12

29 Oct '12

Dear All I have some basic question in regard to file operations. *1. file_manage table* Whenever we use file_save_upload api to upload a file, I can see one corresponding row is added to file_manage table. My question is, the row in file_manage table is temporary one or it will be there always. I am planning to read some information from file_manage table afterwards, if it is just a temporary entry, probably I will be in trouble. *2. File / directory permission* My hosting is a linux based hosting. My understanding is whenever a user uploads a file, finally the web server writes the file to system. So the webserver application is the owner. In my case, first I create a folder (with permission 0755), and then write the file (with permission 0664) to that folder. Next time I want to delete the old file and write a new file it is not possible from same user who wrote the file last time or from any other user. Can somebody explain me why the permission issue comes here as always it is the webserver that writes the file, so virtually owner remains same. If I keep the folder permission 0777 then second time file write is possible. And, by keeping folder permission 0777, am I bringing up a security issue here.... Thanks and Regards Austin

2 1

Subject: Re: Site Hacked
by Roger 29 Oct '12

29 Oct '12

> Pl go to drupal support and give your details and report them about > hacking better change admin password No point in doing that. It's a whole of Drupal design thing, including engine and modules. It is not a small problem. The inherent problems, for us, with Drupal 7 are: - The engine is part of the site and can be played with/altered while live. Convenient but potentially damaging. - There is no way to not have admin on a live site. In fact there should be no admin at all on a live site or as a minimum, a disabling switch. Without admin access a live site is less vulnerable. It can be hidden but not disabled. Live should be just display of data with limited data input and change thereof. This requires another mindset for Drupal as a whole. - For us, some components, that we needed, like say Work bench, taxonomy, and several others need admin permissions for the user to enter/change data. This opens a pandora's box of risk. Alternatively we write work around code or find and install yet another set of "work around" modules to overcome the problem. This in turn introduces potential threats, risks, more maintenance, etc. To date we have several work around modules. Creating modules or rewriting is not an option for me. I do not like PHP, it's boring, cumbersome and repetitive. - Configurations are stored in the database, there is no way to dev or test without entirely separate installs which require copies of the live database updated into the dev/test areas. We can't work on updated data without potentially wrecking d/t changes and vice versa. Ideally configurations could be separate from data. Dev/test could instead be a subset of live data with just the config and display changes worked upon. We don't have the expertise to go through every table to find which is linked to which. - There is no clean, obvious way to move a small change from dev/test to live site without overwriting the database or part thereof which means that latest data may be changed or some field content no longer relates to changes. Unless yet another set of protocols is introduced with more complication. - Introducing changes as above, for us, have wrecked parts of the live system because it seems, virtually every table is referred to by every other table in some way. - When Admin, on a static IP, is locked out there is no way, apart from waiting many hours, for the ip lockout to be dropped. Unless there are 2 or 3 admins and one or those resets the lockout, not easy! - We routinely use extremely convoluted very long passwords, changed regularly. The password is the only hidden part of a log in. User names are displayed to all and sundry. For us, hiding actual user names and displaying preferred user names unrelated to login would be more secure. Barriers to hacking Drupal core are the password and the 5 tries and you're out. Hidden user name and display of preferred, but different name could add another level of security. Roger

2 1

Site Hacked
by Roger 27 Oct '12

27 Oct '12

Hi, My development website (Drupal 7.15) setup 2 weeks ago. Only View and Chaos Tools Suite Modules installed. I contacted hosting company and they said it's compromised through FTP -what I don't believe (if it's truth I'm really screwed because there is tons of other sites too :( ) I got "Security update" message but, since it's development website, I wasn't rushin' What's chances it's really FTP or something else? No other problems but "new" index page. Though, they could "planted" something? We too had very noticable attempts 2-3 weeks ago on one of our Drupal 7 sites. If anyone guesses your user name and password your'e stuffed. I had that almost happen. Caught it just in time We also had our previous Drupal 6 site hacked with some nasty code implanted into the drupal /includes system files. They got in thru the server. The isp is still in denial. Check your drupal logs/reports to see who has got in and how., regularly clean out the logs so you have fresh access detail. I suggest, delete everything on site, very difficult if you only have ftp or cpanel. Clean the site, use a new 18-25 character root password using the most convoluted range of ascii characters you can think of. Never type this when logging in as admin-- copy and paste. Never email the user or password to any one in the same email. Reinstall the full Drupal site and use similarly complex admin password. BE careful....... Drupal locks out your IP address if you enter the incorrect user name or password, I think it's 5 times but am not sure. It happened to me after 3 times. Hope this helps Roger

2 1

Varnish 2.x debugging
by Vaibhav Jain 26 Oct '12

26 Oct '12

Hello Drupal Lovers I am trying to figure out a way to debug Varnish and write some code in VCL file. I am struggling to get all attributes and properties of an object. Is there anything like print_r for varnish too. I am looking at the request object and object is "req", any way to know what all information does it contain ? Hoping to get a reply soon :) -- Regards, Vaibhav Jain

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

support October 2012