CiviCRM Community Forums (archive)

I am wanting to setup a local development machine on a new Lenovo T400 notebook. I have searched this board all day and cannot find a decent solution to this problem. It seems to be a very common problem, however every solution I have found and tried does not solve my problem.

Setup
=====
Lenovo T400 3 GB RAM, Core2 2.4
Windows 7
Drupal 6.15
XAMPP 1.7.0
Apache 2.2.11
PHP 5.2.8 + PEAR
MySQL 5.1.30

Drupal works great out of the box with this setup and all of the core modules. Speed is decent.

However, after I install the CiviCRM module on the above Win7/XAMPP setup AND load the path http://localhost/admin/build/modules in my browser, I receive the following error:

Fatal error: Maximum execution time of 60 seconds exceeded in C:\xampp\htdocs\drupal\includes\file.inc on line 898

Many members on this forum have suggested various workarounds.

NONE OF THESE SOLUTIONS HAVE FIXED MY ISSUE
===========================================
Disable the Drupal Update Module.
Increase the max timeout to over 60s
Increase PHP memory limit to 64MB
Disable AVG, Windows firewall
Modify the Windows Host file
Install a different dev server (e.g. Uniserver)
Fix DNS IP6 in Firefox browser
Make changes to MySQL and switch from InnoDB engine to MyISAM
Install dev module and check MySQL queries. Result: Executed 85 queries in 164.83 milliseconds.

And on and on and on... =(

So, after using my head a bit, I suspected it might have something to do with the index.php process itself.

Using Xdebug and WinCacheGrind to view the data, the following results reveal that I may have found the culprit:

php:is_dir() avg. self time is 3.5 ms x 13,705 function calls = 47.630 secs process time.
php:opendir() avg. self time is 2.7 ms x 1,870 function calls = 5.025 secs process time.
file_scan_directory() avg. self time is 2.6 x 1,865 function calls = 4.793 secs process time.

Total process time of these three calls: 57.448 secs. No wonder it's timing out before 60secs!

Now, this makes sense because when you examine the number of directories in CiviCRM modules folder, there are 4,285 Files, 821 Folders.

One might shrug this off and conclude Drupal is just doing a lot of work during /admin/build/modules, however, when you examine WinCacheGrind a few lines down, I notice this:

php:readdir() avg. self time is ~0.0 ms x 17,440 function calls = 302 ms process times.

Any ideas how I can speed up these calls? Why is readdir() performing more calls than is_dir(), yet the process time it takes is 100x slower? Is there something I can do? Is this something to do with Windows 7 and PHP?

Please help!

Thanks again for your reply.  I found a workaround.  It was simply dropping my Win7/XAMPP setup and switching to an Ubuntu/VirtualBox setup.  Now, all of Drupal's admin pages including CiviCRM fly.

I've posted this problem over on Drupal's Support Forum.  It appears using the PHP function is_dir() on a Windows file system is the bottleneck.  3ms per call doesn't seem slow, but when Drupal calls it 10K times while building one admin page, 30s becomes a real drain on productivity.

Seeing that XAMPP is a very popular development setup, it might be a good idea to promote this issue up the chain regarding this bottleneck between XAMPP and Drupal when running a larger module like CiviCRM.  It would have saved me hours and some hair!

I've just installed xampp and hoping that some work on my xp PC will help in upgrading our drupal / civicrm 1.9 linux server installation to CiviCRM 3.15

Even if I can't run Civicrm, maybe I can get or 237 MB database whittled down to size (mostly activity files).   Perhaps I don't even have to run CiviCRM on my XP machine to use it to help get the database in shape for the upgrade or maybe even the db upgrade.

Dave

howard:

welcome back. we do think that civicrm has improved significantly since 1.0  including import/export/data integration. However there is still a lot to do

Considering that no one on the core team develops on windows (and this is unlikely to change), would be great if folks in the community can group together and help fill that hole (which is the underlying premise of open source after all). building easy to use and deploy installers on all platforms would make an awesome contribution. food for thought.

lobo

The last time I saw that error it was because the PATH environment variable didn't contain the path to PHP. Some things will work, like basic php scripts, but usually anything that needs to load a dll like the mysql dll dies.

You need to restart apache after setting that.

However, there are issue when create a record or search.  I'll probably leave it here for now and work on getting a test version of our CiviCRM 1.9 working on XP or a separate linux server:

Quote

Error Details:

Array
(
    [callback] => Array
        (
            

• => CRM_Core_Error
[1] => handle
        )

    [ code ] => -1
    

[message] => QuickForm Error: unknown error
    [mode] => 16
    [debug_info] => Form rule callback returned invalid value in HTML_QuickForm::validate()
    [type] => HTML_QuickForm_Error
    [user_info] => Form rule callback returned invalid value in HTML_QuickForm::validate()
    [to_string] => [html_quickform_error: message="unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="QuickForm Error: " info="Form rule callback returned invalid value in HTML_QuickForm::validate()"]

Dave

This is php 5.3 related issue.

Glad to see Dave had good luck using the xampp stack - I still can't get CiviCRM to work on the bitnami stack. Their drupal stack installs just fine, drupal 6.16 works fine. Removed all civiCRM files, db, etc and re-installed using different db name and user, same set of issues after 'successful' installation of civiCRM. civiCRM db is there, modules show up in drupal module admin, etc etc but still receive network connection error when clicking on the civiCRM menu link. Nothing in apache logs, nothing in drupal site logs, etc that would point to what's causing it. Played endless games with base url settings, directory path settings, etc. Dave, any chance you can post or email suitably sanitized copies of your config files for drupal and civiCRM? I'd really like to try and isolate this thing so I can get it working. Not sure I have the time at this point to start screwing around with it on another machine, although that would certainly be a possible next step, in order to smoke out possible machine-dependent config issues (nah, that would never happen on windoze). Several demo upcoming demo situations make it really helpful to have this thing running on the laptop and not need a live internet connection. Oh well.
Regards,
Howard

Dave, good advice, thanks. Just to be a little contrarian, I tried the bitnami stack and civi installation on a win2k machine, and of course, it works, using civi 3.2beta1. It's all so typical windoze, so now I will go back and clean out the xp installation and try again, but it's likely something on the particular xp machine is causing the problem. Very frustrating - I'd like to identify exactly what's causing the issue rather than just get it working, in order get to a stable scenario for future use.  Will try xampp if it still won't behave. Having said all that, the installation does run drupal, and created the civi db and such, which would at least let me use it for db work. The drupal backup & migrate module works nicely btw and will give you copies of your drupal and civi db quite easily from its own module admin interface, letting you bypass bigdump and phpmyadmin if all you need is the mysql dump file. My overall goal here is to have the ability to use windoze based db tools to work on things like export and import, db loading and such, by attaching to the mysql tables directly from ms access or workbench or whatever, to allow direct testing, editing, and so forth and test with the live civi installation. That scenario has worked fine in the past, but involved having a separate linux box running the lamp stack and civicrm, and connecting to it over the lan. Easy enough to do but not as portable and convenient as having it all on a laptop.
* * * * *
latest update - did the cleanup and reinstall on the xp laptop, with some minor tweaks, and now it works.  but I don't know why. Will do some checking against saved copies of config files and db to see whether there are any visible differences.
Regards,
Howard