IN case no ones responded.

The Drupal.beavoirs.mybehaviorname = {attach :Mycustomdocumentreadyfunction } is a direct replacement for the document.ready override. You should always use this form in drupal to make sure that you don't have multiple javascript files/functions overidding document.read. Whether you move the code up into your zeroPoint behavior or whether you create a new behavior on the Drupal.behaviors object is a matter of code organization and totally up to you.

Dave

From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Yani Sent: Friday, May 31, 2013 7:32 PM To: support@drupal.org Subject: [support] Jquery code revision...

I need a hint on this... I've mentioned it before but couldn't get my head around it and put it in the too hard basket. Of course it has come back and bitten me again.

What's happening is my JS code is causing some other code to break.

There are 2 ways I've used the JS...

________________________________

(function($) {

Drupal.behaviors.zeroPoint = {

attach : function(context, settings) {

//Drupal Jquery wrapper

Button items in here that call functions

//end wrapper

}

}

})(jQuery);

// Note the wrapper is different for Drupal Behaviors

________________________________

function manageBlocks(menu) {( function($) {

$(document).ready(function() {

// jQuery wrapper

Functions actions in here

//end wrapper

});

})(jQuery);

}

________________________________

Can I just lift the functions up and place them within the top section or do I need to write the bottom section differently.

It just seems odd that this wouldn't be correct as is.

The sort of things it impacts are Facebook blocks that don't update and the file upload MCE losses all JS abilities.

Note... it's been 12 months since I've touched this and I'm most brain dead on it!

Yani

When Javascript encounters an error it will stop processing the rest of the code, with the exception of asynchronous calls that were set before the error and don't depend upon code in the global namespace. Here's a quick example I threw together:

http://jsfiddle.net/HollyIT/n3r9Z/

As far as jQuery 1.8, it's very common for things to break when upgrading jQuery. You might want to check the jquery_update module issues to see if anything is being reported:

https://drupal.org/project/jquery_update

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 6/7/2013 3:06 AM, Yani wrote:

I had a good look at this... (not that you are not absolutely right Dave)

The way I have done this is exactly how this works in using jQuery plugins. The only difference I could detect was in the full use of jquery as opposed to $.

There was an undefined var that occurred on some pages that I put inside a 'if' which solved the major issue being that the code broke the JS in the IMCE file upload. I wouln't have thought an undefined var would break code in other modules but there you go.

An outstanding issue now is that the code fails if I move from jQuery 1.7 > 1.8. That could well apply to other modules as well. Most likely I'll ignore the issue, and at some point it will bite me again. J

Yani

*From:*support-bounces@drupal.org [mailto:support-bounces@drupal.org] *On Behalf Of *Metzler, David *Sent:* Tuesday, 04 June 2013 1:24 AM *To:* support@drupal.org *Subject:* Re: [support] Jquery code revision...

IN case no ones responded.

The Drupal.beavoirs.mybehaviorname = {attach :Mycustomdocumentreadyfunction } is a direct replacement for the document.ready override. You should always use this form in drupal to make sure that you don't have multiple javascript files/functions overidding document.read. Whether you move the code up into your zeroPoint behavior or whether you create a new behavior on the Drupal.behaviors object is a matter of code organization and totally up to you.

Dave

*From:*support-bounces@drupal.org [mailto:support-bounces@drupal.org] *On Behalf Of *Yani *Sent:* Friday, May 31, 2013 7:32 PM *To:* support@drupal.org *Subject:* [support] Jquery code revision...

I need a hint on this... I've mentioned it before but couldn't get my head around it and put it in the too hard basket. Of course it has come back and bitten me again.

What's happening is my JS code is causing some other code to break.

There are 2 ways I've used the JS...

---

(function($) {

Drupal.behaviors.zeroPoint = {

attach : function(context, settings) {

//Drupal Jquery wrapper

*/Button items in here that call functions/*

//end wrapper

}

}

})(jQuery);

// Note the wrapper is different for Drupal Behaviors

---

function manageBlocks(menu) {( function($) {

$(document).ready(function() {

// jQuery wrapper

*/Functions actions in here/*

//end wrapper

});

})(jQuery);

}

---

Can I just lift the functions up and place them within the top section or do I need to write the bottom section differently.

It just seems odd that this wouldn't be correct as is.

The sort of things it impacts are Facebook blocks that don't update and the file upload MCE losses all JS abilities.

*Note... it's been 12 months since I've touched this and I'm most brain dead on it!*

Yani

Drivers are loaded in the php.ini file. Depending on how PHP is installed, chances are you have a couple of php.ini files. One is for the webserver and the other is for CLI.

You can find the location of the php.ini file the CLI is using by running this command:

php -i | grep Loaded

To check if that configuration file has PDO support in it:

php -i | grep PDO

You should get back something like this:

PDO PDO support => enabled PDO drivers => mysql, odbc, sqlite PDO Driver for MySQL => enabled PDO_ODBC PDO Driver for ODBC (unixODBC) => enabled PDO Driver for SQLite 3.x => enabled

If not, then you need to enable the extensions in php.ini.

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 6/1/2013 11:29 AM, Tim Johnson wrote:

• Jamie Holly hovercrafter@earthlink.net [130601 07:11]:

...

Plop <?php phpinfo(); ?> into a file and load that in your browser to make sure PDO is actually loading. You should also have the base pdo driver there (pdo.so) and that along with whatever databases you want to use need to be loaded through php.ini as such:

extension=pdo.so extension=pdo_mysql.so

Thanks Jamie : I have already done phpinfo - and I have PDO loading.

I'm just getting to it but I believe that for drush in cli mode, I need a alias or a switch for 'drush updb' to tell it what driver to use.

Will report back. cheers

...

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 5/31/2013 7:31 PM, Tim Johnson wrote:

...

I've got drupal 7 and drush on Mac OSX 10.7 The original PHP install (as shipped) is 5.3.25.

with that configuration I was able to upgrade drupal sites running locally for several occassions.

One site used sqlite, the other mysql.

Now I have installed PHP 5.4.15, as well as the mysql and sqlite drivers for php54.

Now when I run drush updb, I get the following:

A PDO database driver is required! You need to enable the PDO_SQLITE (or PDO_MYSQL) database driver for PHP 5.2.4 or higher so that Drupal 7 can access the database.

I find Applications/MySQLWorkbench.app/Contents/Resources/libraries/pysqlite2/_sqlite.so /opt/local/lib/php54/extensions/no-debug-non-zts-20100525/pdo_sqlite.so and opt/local/lib/php54/extensions/no-debug-non-zts-20100525/mysql.so /opt/local/lib/php54/extensions/no-debug-non-zts-20100525/pdo_mysql.so

Worse, if I set the php execute as php54, drush freezes on the drush updb command. No error messages, just stalls.

This is a mess. I feel that I am back in linux 6 dependency hell!

BTW: Those of you who might be using homebrew and would recommend that I convert, would be on the right track but unfortunately I have over 200 _active_ packages installed via macports.

Where do I start?

thanks

-- [ Drupal support list | http://lists.drupal.org/ ]

Try:

php --ini

That will list all loaded configuration files.

If nothing is showing up, then you need to figure out where PHP was configured to look for configuration files when it was compiled.

php -i | grep Configure

Look for:

--with-config-file-path --with-config-file-scan-dir

That will give you the direcories PHP is configure to look for the ini file in. If you can't find anything there, then you need to ask on the support list/forum for wherever you downloaded PHP from. This is one of those things that is very distribution dependent.

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 6/1/2013 2:16 PM, Tim Johnson wrote:

• Jamie Holly hovercrafter@earthlink.net [130601 08:25]:

...

Drivers are loaded in the php.ini file. Depending on how PHP is installed, chances are you have a couple of php.ini files. One is for the webserver and the other is for CLI.

Aha!

...

You can find the location of the php.ini file the CLI is using by running this command:

php -i | grep Loaded

To check if that configuration file has PDO support in it:

php -i | grep PDO

You should get back something like this:

PDO PDO support => enabled PDO drivers => mysql, odbc, sqlite PDO Driver for MySQL => enabled PDO_ODBC PDO Driver for ODBC (unixODBC) => enabled PDO Driver for SQLite 3.x => enabled

If not, then you need to enable the extensions in php.ini.

OK. This is what I have : ###################################### linus:rocky tim$ php -i | grep Loaded Loaded Configuration File => (none) libXML Loaded Version => 20900 linus:rocky tim$ php54 -i | grep PDO PDO PDO support => enabled PDO drivers => mysql, sqlite PDO Driver for MySQL => enabled PDO Driver for SQLite 3.x => enabled ###################################### So... php (cli) is not finding a php.ini.

Where should it go?

BTW: php -i opens up a whole lot of analysis - thanks for that edification.

Tim,

In this exchange I notice you're using PHP 5.4. Drupal is not ready for PHP 5.4 and will cause you issues. By the time D8 becomes fully available it is possible that it will be usable with 5.4. D6 will never be and D7 is patched occasionally but certainly not to the extent that D8 is.

Earnie

On Sat, Jun 1, 2013 at 3:58 PM, Tim Johnson tim@akwebsoft.com wrote:

• Jamie Holly hovercrafter@earthlink.net [130601 11:40]:

...

Try:

php --ini

That will list all loaded configuration files.

If nothing is showing up, then you need to figure out where PHP was configured to look for configuration files when it was compiled.

php -i | grep Configure

Look for:

--with-config-file-path --with-config-file-scan-dir

That will give you the direcories PHP is configure to look for the ini file in. If you can't find anything there, then you need to ask on the support list/forum for wherever you downloaded PHP from. This is one of those things that is very distribution dependent.

Thanks again. I have located /opt/local/etc/php5/php.ini-development and copied it to php.ini Now I have configuration file. I'm still not showing the drivers. FYI: This php was shipped with the OS, so I will try my macports ML and if no help there, I will get on a PHP forum.

Have you a recommendation?

In the meantime, running update.php from drupal itself does the job, it's just that I really like drush. cheers -- Tim tim at tee jay forty nine dot com or akwebsoft dot com http://www.akwebsoft.com -- [ Drupal support list | http://lists.drupal.org/ ]

You copied the file, but you didn't configure it. The production files don't come with PDO enabled. You need these lines in there:

extension=pdo.so extension=pdo_mysql.so

(NOTE: Those lines are in there, but they are commented out by default. Depending on what has been done with the distribution, they most likely also try to load .dll files, which are for WIndows.)

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 6/1/2013 3:58 PM, Tim Johnson wrote:

• Jamie Holly hovercrafter@earthlink.net [130601 11:40]:

...

Try:

php --ini

That will list all loaded configuration files.

If nothing is showing up, then you need to figure out where PHP was configured to look for configuration files when it was compiled.

php -i | grep Configure

Look for:

--with-config-file-path --with-config-file-scan-dir

That will give you the direcories PHP is configure to look for the ini file in. If you can't find anything there, then you need to ask on the support list/forum for wherever you downloaded PHP from. This is one of those things that is very distribution dependent.

Thanks again. I have located /opt/local/etc/php5/php.ini-development and copied it to php.ini Now I have configuration file. I'm still not showing the drivers. FYI: This php was shipped with the OS, so I will try my macports ML and if no help there, I will get on a PHP forum.

Have you a recommendation?

In the meantime, running update.php from drupal itself does the job, it's just that I really like drush. cheers

Glad you got it solved. I did say that you did copy it, but you still need to configure it (depending on distribution). The php.ini-production file that ships with PHP has PDO disabled by default. You can verify this in the source:

https://github.com/php/php-src/blob/master/php.ini-production#L893

; comments out the lines in .ini files.

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 6/2/2013 8:57 PM, Tim Johnson wrote:

• Jamie Holly hovercrafter@earthlink.net [130602 16:31]:

...

You copied the file, but you didn't configure it. The production files don't come with PDO enabled. You need these lines in there:

extension=pdo.so extension=pdo_mysql.so

Thanks Jamie, but I _did_ copy the file, I just did not explicitly state so to the ML. Marking this as solved ...