support

support@drupal.org

7912 discussions

how tackle forms
by steven＠vermoere.net 11 Apr '13

11 Apr '13

Hello, I'm looking at a way that it is possible that (anonymous) users enter some data in predefined fields. The result is shown and searchable on the website and everybody can give comments. It must be moderable. You must be able to open and close the questionaire. How can I tackle this ?

6 6

How do I allow viewing of certain user profile fields without allowing viewing of the user profile?
by Steve Wickham 11 Apr '13

11 Apr '13

Hello and I hope someone can help me. I have a situation where I need to allow 3 user profiles fields which are computed from the values of other user profile fields to be viewable by other anonymous and authenticated users. To be more specific I have the computed fields Full Name, Public Phone, and Public Email which are computed from the values of other profile fields and only have values if the user checks the user profile field called "List in Public Directory". I have the field permissions module installed which allows the setting of permissions by field, and I have set these 3 fields to be viewable by anonymous and authenticated users. But no fields are viewable by other anonymous and authenticated users, even the non-computed fields, unless I set the general permission of "View user profiles" for those roles. Anyone have any ideas how I can get around this? I'm also posting this issue in the field permissions module issue queue, but I'm open to any solution. Thanks for any and all help in advance! Steve

3 5

Re: [support] support Digest, Vol 124, Issue 13
by Roger 10 Apr '13

10 Apr '13

On 04/10/2013 10:00 PM, support-request(a)drupal.org wrote: > I did ask exactly what you are running, the modules list is one part of > that. > What are these modules? > custom > old_token > error_log > > I'd also like the output of > rpm -qa > > and to know what is in /usr/local and /opt > > I ran drush with your modules list, and those three modules are not > available to me. Apologies, I didn't take that to mean module list, oops. Ok so now you've got me piqued, I'll investigate ! error_log seems to be: [06-Mar-2012 11:08:19] PHP Warning: Cannot load module 'XCache' because conflicting module 'eAccelerator' is already loaded in Unknown on line 0 [06-Mar-2012 11:09:51] PHP Warning: Cannot load module 'XCache' because conflicting module 'eAccelerator' is already loaded in Unknown on line 0 [06-Mar-2012 11:10:06] PHP Warning: Cannot load module 'XCache' because conflicting module 'eAccelerator' is already loaded in Unknown on line 0 [06-Mar-2012 11:22:57] PHP Warning: Cannot load module 'XCache' because conflicting module 'eAccelerator' is already loaded in Unknown on line 0 [06-Mar-2012 11:23:05] PHP Warning: Cannot load module 'XCache' because conflicting module 'eAccelerator' is already loaded in Unknown on line 0 I have never found a way around this error series. I do not have eAccelerator, at least it does not show up with any searches. old_token, I cannot find so looked at token_old which contains token_test.module <?php /** * @file * Helper module for token tests. */ /** * Implements hook_exit(). */ function token_test_exit() { if ($debug = variable_get('token_page_tokens', array())) { $debug += array('tokens' => array(), 'data' => array(), 'options' => array()); foreach (array_keys($debug['tokens']) as $token) { $debug['values'][$token] = token_replace($token, $debug['data'], $debug['options']); } variable_set('token_page_tokens', $debug); } } /** * Implements hook_date_format_types(). * * @todo Remove when http://drupal.org/node/1173706 is fixed. */ function token_test_date_format_types() { $info['token_test'] = t('Token test date format');/** * @file * Helper module for token tests. */ // Explicitly set the variable here as well. variable_set('date_format_token_test', 'Y'); return $info; } custom module contains hidefield.module I'm thinking this one was created by the other dev person before he went away. It hides a checkbox that workbench puts up and should be only an admin operation, I do remember him talking about this some 6-10 weeks ago. <?php /** * @file * Allows administrators to hide specific fields from users. * * Hides fields depending upon the user. */ function hidefield_form_alter(&$form, &$form_state, $form_id) { global $user; // check that the user is not the reviewer and also not anonymous (...to avoid error messages when logging out). if ($user->uid != 0 && $user->name != 'Revwer1-8') { // Hide the checkbox $form['field_quality_assured'] = array( '#type' => 'hidden', ); } }

2 1

Fed up with Drupal 7 ..., Desperately.....modules.etc
by Roger 10 Apr '13

10 Apr '13

Thank you David. Apologies for the length of this message. I don' really think we've gotten off topic, there was never a consideration of throwing hardware at the problem of memory failure caused by Add Content type. <snip> and that your memory consumption is not that of a typical Drupal install </snip> --Why then did the problem not exist a few weeks ago? --Why does it not exist on my home machines which I use to access the server? and which have identical copies of the site installed. I can run both the site copy on localhost and the remote site from the server side by side on my monitor. Adding a content type on localhost does not fail, but doing the same on remote site does fail. As I understand it my localhost Apache server runs both. I do not know if my php runs the code from the remote server. Same result in Fedora 18, Fedora 16, Ubuntu 12.10, php5.3 and php 5.4 on both machines, so many alternatives produce identical results. --What changed between then and now? No modules or views have been added or removed for 4 months (proviso: unless another dev installed a module I do not know about but he's not around so I cannot ask). <snip> if you've got any non-standard modules </snip> The module list I installed with Drush from the Drupal.org site is listed below. <snip> That is why many continue to ask for your module list. They're trying to figure out if you've got any non-standard modules that might have a leak or performance problem. </snip> I didn't read any asking for a module list but this is it, and below are the lists of what's loaded when I click on <add a content type>. I have no idea why so many superfluous @imports and script calls are made, even the jQuery seems to refer to modules of which most have nothing to do with adding a content type. Maybe there is a memory leak in one of these. Modules: addanother admin_menu auto_nodetitle backup_migrate calendar captcha ckeditor content_access ctools custom date devel entity entityreference error_log exclude_node_title features file_entity finder flood_control imce libraries link masquerade media module_filter nat noreqnewpass omega_tools override_node_options pathauto print references relation rules security_review term_reference_tree token_old variablecheck views views_bulk_operations views_php views_slideshow view_unpublished workbench workbench_access workbench_moderation -----------==============---------- <head profile="http://www.w3.org/1999/xhtml/vocab"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="shortcut icon" href="http://www.mysite/misc/favicon.ico" type="image/vnd.microsoft.icon" /> <meta name="Generator" content="Drupal 7 (http://drupal.org)" /> <title>Content types | Eckankar in Australia</title> <style type="text/css" media="all">@import url("http://www.mysite/modules/system/system.base.css?mkt7v4"); @import url("http://www.mysite/modules/system/system.menus.css?mkt7v4"); @import url("http://www.mysite/modules/system/system.messages.css?mkt7v4"); @import url("http://www.mysite/modules/system/system.theme.css?mkt7v4");</style> <style type="text/css" media="all">@import url("http://www.mysite/modules/system/system.admin.css?mkt7v4");</style> <style type="text/css" media="all">@import url("http://www.mysite/sites/all/modules/calendar/css/calendar_multiday.css?mkt7…"); @import url("http://www.mysite/sites/all/modules/date/date_api/date.css?mkt7v4"); @import url("http://www.mysite/sites/all/modules/date/date_popup/themes/datepicker.1.7.c…"); @import url("http://www.mysite/sites/all/modules/date/date_repeat_field/date_repeat_fiel…"); @import url("http://www.mysite/modules/field/theme/field.css?mkt7v4"); @import url("http://www.mysite/modules/node/node.css?mkt7v4"); @import url("http://www.mysite/modules/search/search.css?mkt7v4"); @import url("http://www.mysite/modules/user/user.css?mkt7v4"); @import url("http://www.mysite/sites/all/modules/views/css/views.css?mkt7v4");</style> <style type="text/css" media="all">@import url("http://www.mysite/sites/all/modules/ckeditor/ckeditor.css?mkt7v4"); @import url("http://www.mysite/sites/all/modules/ctools/css/ctools.css?mkt7v4"); @import url("http://www.mysite/sites/all/modules/views_slideshow/views_slideshow.css?mkt…"); @import url("http://www.mysite/sites/all/modules/finder/modules/finder_ui/finder_ui.css?…"); @import url("http://www.mysite/sites/all/modules/ctools/css/dropbutton.css?mkt7v4"); @import url("http://www.mysite/modules/toolbar/toolbar.css?mkt7v4"); @import url("http://www.mysite/modules/shortcut/shortcut.css?mkt7v4");</style> <style type="text/css" media="screen">@import url("http://www.mysite/themes/seven/reset.css?mkt7v4"); @import url("http://www.mysite/themes/seven/style.css?mkt7v4");</style>    <script type="text/javascript" src="http://www.mysite/misc/jquery.js?v=1.4.4"></script> <script type="text/javascript" src="http://www.mysite/misc/jquery.once.js?v=1.2"></script> <script type="text/javascript" src="http://www.mysite/misc/drupal.js?mkt7v4"></script> <script type="text/javascript" src="http://www.mysite/misc/jquery.cookie.js?v=1.0"></script> <script type="text/javascript" src="http://www.mysite/sites/all/modules/admin_menu/admin_devel/admin_devel.js?m…"></script> <script type="text/javascript" src="http://www.mysite/sites/all/modules/views_slideshow/js/views_slideshow.js?m…"></script> <script type="text/javascript" src="http://www.mysite/sites/all/modules/ctools/js/dropbutton.js?mkt7v4"></script> <script type="text/javascript" src="http://www.mysite/sites/all/modules/finder/modules/finder_ui/finder_ui.js?m…"></script> <script type="text/javascript" src="http://www.mysite/misc/tableheader.js?mkt7v4"></script> <script type="text/javascript" src="http://www.mysite/modules/toolbar/toolbar.js?mkt7v4"></script> <script type="text/javascript"> <![CDATA[//><!]]>

2 2

Fed up with Drupal 7 ..., Desperately.....modules.etc
by Roger 09 Apr '13

09 Apr '13

>> Funny thing is my machines do not exhibit lack of memory. I run <System >> >Monitor> most of the time and do "top" checks in a terminal frequently. >> >I mentioned in a previous email that I had tested this on my machine and >> >went as far as 2048M but after 512M the problem worsened by degrees, so >> >throwing more memory isn't the solution. >> >Roger > Exactly what is running on the shared hosting system? Maybe you can > replicate that? > Shared Hosting system runs Centos 6.4 php 5.3, cpanel and WHM. Our site has 2 Drupal 7.22 installations. The php memory error problem did not exist 1 month ago.

2 1

Fed up with Drupal 7 ... Desperately.....modules.etc
by Roger 08 Apr '13

08 Apr '13

Thank you for this in depth discussion it is much appreciated, and yes, I do appreciate the ease with which Drupal "sets up" a full blown site. I also very much appreciate the highly professional way people respond, no flame wars, no ridicule, just patient insightful information. Thank you. My observations to date: -- Our server runs Centos 6 and php 5.3 -- Drupal is a great system but can suffer from less than optimal module coding as explained below. -- Some sites have 60 and more modules and work flawlessly. -- Our site works flawlessly for the most part. -- We have 41 modules soon to be about 45ish when I start the newsletter system so number of modules, in our case, is not a problem because most are not used in normal operation or called infrequently but are still required. -- We have a very minimal site with very low demand from users, minimal demand on modules, minimal calls on database (until I get the newsletter system working) and few display calls, little of the below discussion relates to our requirements. -- Add Content Type is still a problem, it seems to unexpectedly fail. -- Based on a previous response, adding a Content Type, seems to have much broader issues with far greater overhead than I first understood. -- Apart from altering php memory_limit, which works sometimes but has wider implications for the whole site, there is no definitive answer to this Add Content Type problem. --There seems to be no pressing need to have greater than 128M allocated to PHP. Our ISP support team advise against increasing above 128M. Conclusion: It seems that Add Content Type puts outrageously heavy demand on a system. Why it has 17 includes unrelated to creating a content type, Calls 18 scripts, all but node/content_types, completely unrelated and unnecessary at this point, a huge jQuery that has nothing at all to do with anything, irrelevant menu lists that are switched off, not in use, or not in the least related to this display, I am not sure. Reading about Ruby on Rails and separating out the business logic from data and views. Looking at the underlying code for Drupal Add Content Type it seems there is a need to separate out much of the business logic. But I do not know if this can be done with PHP. As below, optimising Drupal means stripping things away, but when faced with this, stripping can't help much. Roger <snip> Every module is coded in a different way. While some can be benign, others might be less so. Some modules create additional load because they force pages to be re-rendered, or for permissions to be re-checked and so forth. This is a community-project, which means lots of free great code, but also not everything is coded perfectly at all times, since everyone is contributing in an open source fashion. Each module that is activated also creates some additional function calls, depending on the functions found, those functions will either run once and be cached, or be perpetually accessed every time their hook_ is called. Is adding one more hook_ a problem? Not inherently, but clearly the more you add, the more calls need to be made. If you want a system that can handle hundreds of modules, each with potentially tens of functions, each of which is doing a calculation then surely that increases your server's stress? There is nothing magic about any CMS, it is, as you say, just a bunch of PHP code. An optimal system needs careful consideration. If you want a site like facebook, where you are dealing with tremendous stress considerations, you generally just build the site up from scratch. No CMS, you put all the parts together, with the absolute zero-line that anything non-essential is scrapped. If you have the budget to build your site from the ground-up, you just don't bother with any CMS and build your own (or use an extremely lightweight framework as your base point). Drupal gives you a lot out of the box, not many CMS's can crunch out full blown applications with such flexibility and extensibility, but flexibility comes with a price. Optimizing Drupal sometimes involves stripping things away, researching how things were done by others, and improving the code that others have made. Your question and concern is extremely general, so it is hard to give you anything concrete in return. Can you run a complex application on Drupal? Absolutely Can you run a site that has an extremely fast response time? Most definitely Can Drupal be used on a website that has high traffic, sometimes with burst traffic intervals? For sure can I get a high performant site, by installing any module I find on the net, keeping it on, and just expect that clicking "setup" is enough to achieve high performance, and high speed? Doubtful? You need to be good at web development to be good at performance and optimization. It is a very complex subject, and many solutions, depending on need, can bring you beyond drupal, to things like memcache / apache / mysql optimization. Drupal gives you a giant flexible application building API/environment. You then need to take care of it to make sure it retains high performance. Hope this helps! -- Info Razor Sent with Sparrow (http://www.sparrowmailapp.com/?sig) </snip>

4 10

Fed up with Drupal 7 ..., Desperately.....modules.etc
by Roger 07 Apr '13

07 Apr '13

On 04/07/2013 07:24 PM, support-request(a)drupal.org wrote: > If he's still testing on Fedora, then testing on CentOS is essential. > Fedora is quite likely to be broken, but probably better than Apache's > apache and PHP's PHP because they have undergone additional testing and > hammering by Good Folk from Drupal, Joomla, Wordpress and any other > significant open source project using PHP. > > I think it has to be something not certified such as Drupal or Roger. Yep I tend to agree but do not know what to look for... Will, hopefully know more, when CentOS is up and running. Roger

1 0

Fed up with Drupal 7 ..., Desperately.....modules.etc
by Roger 07 Apr '13

07 Apr '13

Hi Peter. Thank you, I will keep this in mind. Far as I can tell the problem is not on my machines but on the remote server. I have no way of achieving any of your suggestions. There's no need for the below on my old Fedora 16 which has old apache and php5.3 and produces the same errors when Adding a Content Type on the remote server. Databases, tables, etc all "seem" correct. Copies work on my machines. Cheers Roger > Hi Roger, > > I still wonder why don't you do this: > > 1. Downloads and install from source apache & php 5.3. There are penty > of tutorials how to do this. Compile only php modules you need.(!) > > 2. Install in/usr/local/ (It goes there by default) > > 3. Modify firewall to allow port 8080 > > 4. Edit httpd.conf of the newly compiled Apache so you have correct > DocumentRoot and make it listen 8080. > > 5. Start the new Apache on 8080 > > 6. Check how site behaves on port 80 and port 8080. > > A) If it is better on 8080 shut down primary Apache, and change teh > port of the new one on 80. > > B) If it is the same, check database - run check and repair mysql tables > - might be broken indexes or something. > > > Peter

1 0

Fed up with Drupal 7 .Desperately.....modules.etc
by Roger 07 Apr '13

07 Apr '13

On 04/07/2013 07:24 PM, support-request(a)drupal.org wrote: > You can safely increase memory limit to much higher value. > > The price of a block of RAM is very small. Increase php memory limit to > 512Mb and see how it goes. That might the simplest solution to try:-) No, we can't do that on a shared server. Roger

1 0

Re: [support] Fed up with Drupal 7 ... Desperately.....modules.etc
by Roger 06 Apr '13

06 Apr '13

Memory limits of 128mb or more is not uncommon. It's even stated in the online documentation: A PHP memory limit of 32MB is the minimum requirement for Drupal 7 (16MB for Drupal 6), and 64MB is recommended. Some sites may need more than 64MB if they are using certain contributed modules such as Views and Panels. Memory limits of 128MB and higher are not unusual. There are several techniques to increase the PHP memory limit and you only need to use one of them. The right one for you depends on your system configuration. http://drupal.org/node/207036 Views and Panels are heavy modules. That's the price we pay for the ease in site building they provide. The other option is to not use them and go with custom code to generate your content and displays. Any site I build I evaluate what needs to be done and what will need to be done in the future before installing Views and/or Panels. Of course that's not an easy option for people not familiar with Drupal development. As far as Views, it will get better in Drupal 8, since it is going into core and will get a lot more attention from the development side as well as tighter integration into Drupal overall. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 4/5/2013 2:26 AM, John Summerfield wrote: >> >On 05/04/13 00:28, Jamie Holly wrote: >>> > >I've got a Drupal 7 site running with 60 contrib modules and about a >>> > >dozen custom modules. I got the memory limit set to 128mb and never run >>> > >out of memory. This is on CentOS6 and PHP 5.3.23. There are also >>> > >countless other Drupal 7 sites running out there with no problem. But >>> > >you can pretty much break anything with the wrong configurations and/or >>> > >modules. >> > >> >In contrast, I just created a site with a few modules and themes, and >> >without adding so much as any new content type or content, I did get >> >memory problems >> > >> >I'm using CentOS 6. PHP 5.3.3 with all the latest relevant updates. It >> >happened the first day drupal 7.22 was available and it appeared to be >> >provoked by Jackson. Not having persuaded myself I actually want >> >Jackson, it was easy to dispense with it. I do have the memory limit set >> >to 128Mbytes. >> > >> >However, this isn't Roger's problem. >> > Apologies for not snipping the above but the discussion encapsulates a number of my experiences. When installing Drupal, there should be no reason to jump through hoops to configure just because of Drupal, this seems to imply a fault with the Drupal installation or pre configuration. We can't always blame the user. Yes I agree it happened on earlier releases of Drupal 7. I find that a brand new install with minimal modules and no data or configuration changes will cause the Fatal memory error and have experienced this on 3 unrelated computers and 3 different operating systems. I have tried memory settings between 64M and 512M, even went to 1024M, half the memory on one of my machines. Interesting to note that each test resulted in a different Fatal error allowance report , except the 1024M which almost doubled the numbers of the original 64M. Side note. I just updated the server to Drupal-7.22 and the Fatal memory problem remains. But not on my home systems to which I copied the whole file system and database. I have no way of addressing shared server issues other than /settings.php so thinking if Views and Panels, etc are a problematic Drupal overhead and it's better to build from scratch, Drupal becomes an increasing burden. I think I'll gradually move away from Drupal. Seems it's pretty much, not worth the effort. Roger

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

support