I'm converting a module from Drupal 5 to Drupal 6, and I'm having a very hard time understanding the change in the use of 'op'. I can't figure out how I need to change my code. There are these lines. if (!empty($form_values['op'])) { _phpfreechat_clear_cache(); _phpfreechat_clear_cookies(); } if (!_phpfreechat_check_install()) { form_set_error('op', _phpfreechat_not_found()); } if (!_phpfreechat_check_files()) { form_set_error('op', t('Unable to create data folders for phpfreechat.')); } I took this module over from someone else, so I don't fully understand the use of 'op' here to begin with. Not understanding what it's doing makes it very hard to rewrite. I've spent the last two hours on the Drupal site trying to figure it out and I'm boggled. All I can tell is that 'op' was the default name of buttons in Drupal 5, but I still can't figure out what's being tested in these "if" statements or how I need to rewrite them for Drupal 6. Any guidance you can give me would be greatly appreciated! - Sheryl

This is clearly in either a form _submit or _validate handler, so you'll want to read, and understand: http://drupal.org/node/144132#buttons Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk 2009/1/21 Stewart Robinson <stewsnooze@gmail.com>:

Hi,

Op means different things in different places, or at least its values do.

What function does your copied code come from and do you know the value of op?

Stew

On 1/21/09, Sheryl (Permutations Software) <sheryl@permutations.com> wrote:

...

I'm converting a module from Drupal 5 to Drupal 6, and I'm having a very hard time understanding the change in the use of 'op'. I can't figure out how I need to change my code. There are these lines.

if (!empty($form_values['op'])) { _phpfreechat_clear_cache(); _phpfreechat_clear_cookies(); } if (!_phpfreechat_check_install()) { form_set_error('op', _phpfreechat_not_found()); } if (!_phpfreechat_check_files()) { form_set_error('op', t('Unable to create data folders for phpfreechat.')); }

I took this module over from someone else, so I don't fully understand the use of 'op' here to begin with. Not understanding what it's doing makes it very hard to rewrite. I've spent the last two hours on the Drupal site trying to figure it out and I'm boggled. All I can tell is that 'op' was the default name of buttons in Drupal 5, but I still can't figure out what's being tested in these "if" statements or how I need to rewrite them for Drupal 6. Any guidance you can give me would be greatly appreciated!

- Sheryl

-- Sent from my mobile device

On Jan 21, 2009, at 1:11 AM, Stewart Robinson wrote:

Hi,

Op means different things in different places, or at least its values do.

What function does your copied code come from and do you know the value of op?

'op' doesn't mean anything with forms in Drupal 6. From http://drupal.org/update/modules/ I was able to find this page: http://drupal.org/node/144132 which is titled Drupal 5.x to 6.x form changes. Here are a few excerpts from that page:

$form_state['clicked_button'] A full copy of the button element that was clicked to submit the form. This is more reliable than the old $form_values['op'] name, and also carries any additional information that was placed in the button element's form definition.

and

The 'op' element in the form values is deprecated and should not be relied upon As discussed above, each button can have #validate and #submit functions associated with it. Thus, there should be one button that submits the form and which invokes the normal $form_id_validate and $form_id_submit handlers. Any additional buttons which need to invoke different validate or submit functionality should have button- specific functions. Note also that the 'op' element in the form values, corresponding to the button clicked when there are several in a form in Drupal 5.x, should no longer be relied upon and may not be present.

-Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net

$form_values['op'] is the '#value' of the clicked button on a form, so I'd guess if it were empty, then then the form hasn't been submitted yet. Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk 2009/1/21 Sheryl (Permutations Software) <sheryl@permutations.com>:

Please - I don't need links or excerpts from the linked pages. I've read the docs. I can't see how to apply what is written to this module code.

Is there anyone here who can add something to what is already in the docs - fill in the missing piece for me?

Thank you.

-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Michael Prasuhn Sent: Wednesday, January 21, 2009 5:10 AM To: development@drupal.org Subject: Re: [development] converting a module from Drupal 5 to Drupal 6

On Jan 21, 2009, at 1:11 AM, Stewart Robinson wrote:

...

Hi,

Op means different things in different places, or at least its values do.

What function does your copied code come from and do you know the value of op?

'op' doesn't mean anything with forms in Drupal 6.

From http://drupal.org/update/modules/ I was able to find this page: http://drupal.org/node/144132 which is titled Drupal 5.x to 6.x form changes.

Here are a few excerpts from that page:

...

$form_state['clicked_button'] A full copy of the button element that was clicked to submit the form. This is more reliable than the old $form_values['op'] name, and also carries any additional information that was placed in the button element's form definition.

and

...

The 'op' element in the form values is deprecated and should not be relied upon As discussed above, each button can have #validate and #submit functions associated with it. Thus, there should be one button that submits the form and which invokes the normal $form_id_validate and $form_id_submit handlers. Any additional buttons which need to invoke different validate or submit functionality should have button- specific functions. Note also that the 'op' element in the form values, corresponding to the button clicked when there are several in a form in Drupal 5.x, should no longer be relied upon and may not be present.

-Mike

__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net

Use form_set_error (http://api.drupal.org/api/function/form_set_error/6) and call it with the first parameter as 'NULL', then the error will be set on the form as a whole, not an individual element. Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk 2009/1/21 Sheryl (Permutations Software) <sheryl@permutations.com>:

Ah! This helps. Thank you!! So in Drupal 6 I would change this to:

if ($form_state['submitted'] == false) {}

Correct?

Now I just have that other mystery:

if (<something wrong with module installation>) { form_set_error('op', _phpfreechat_not_found()); }

I'm guessing that this prevents the user from submitting the admin form if the module isn't installed correctly. (I need to confirm by causing the error and seeing what happens in the admin form.)

In Drupal 6, how do I set a general form error that is not related to a particular field? Or maybe the question is... In Drupal 6, how do I set a form error tied to the submit button?

-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Steven Jones Sent: Wednesday, January 21, 2009 11:49 AM To: development@drupal.org Subject: Re: [development] converting a module from Drupal 5 to Drupal 6

$form_values['op'] is the '#value' of the clicked button on a form, so I'd guess if it were empty, then then the form hasn't been submitted yet.

Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites

Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk

I figured out what the module code was trying to do by creating the error. It's actually not well implemented even in Drupal 5, but I don't know if there is a function in Drupal to handle the case. When the administration form for the module is first loaded, the code checks to see if the module has been correctly installed. If it hasn't, it displays an error message at the top of the form. It attributes the error to the submit button just as a convenience. But the user still can see and submit the form. Ideally, there would be a form initialization function that checked that all was well before the form was even displayed. If all was not well, the user would see the error message, but no admin form. I don't see a _form_initialize function anywhere in Drupal. Is it there somewhere and I missed it? If not, it might be a good thing to add. In the meantime, how do I get the name of the submit button so I can use the same technique the module is currently using, but rewritten for Drupal 6? The button is not explicitly defined anywhere in the code - it must be using defaults. Also, according to the Drupal 6 docs, the name for buttons assigned by the system is 'op' - suggesting that the existing code is already correct: http://api.drupal.org/api/file/developer/topics/forms_api_reference.html The following is a list of default values which do not need to be set (found in system_elements): button #name = 'op' #button_type = 'submit' #executes_submit_callback = FALSE #ahah['event'] = 'click' ------------------------------------- Thus this statement is exactly correct for what I want to do, even in Drupal 6: form_set_error('op', 'error text'); Am I missing something here? -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jakob Petsovits Sent: Wednesday, January 21, 2009 2:09 PM To: development@drupal.org Subject: Re: [development] converting a module from Drupal 5 to Drupal 6 On Wednesday, 21. January 2009, Steven Jones wrote:

Use form_set_error (http://api.drupal.org/api/function/form_set_error/6) and call it with the first parameter as 'NULL', then the error will be set on the form as a whole, not an individual element.

form_set_error() encloses the error assignment in this if-condition: if (isset($name) && !isset($form[$name])) { (...set the form error...) } which means when the first parameter ($name) is NULL then no error will be set. It seems you need to set the error for any of your form elements, presumably the submit button in your case was used because the submit button was the only element that's remotely suitable for that error. You might use the actual submit button as error target in Drupal 6 (...I think that should work) by doing a form_set_error('mybuttonname', t('message')) or - alternatively, same effect - form_error($form['mybuttonname'], t('message')). Cheers, Jakob

The simple solution: Under the _menu hook where you define the settings page 'page callback'=>'mymodule_setttings_page' Then create that new function function mymodule_settings_page(){ if (!function_to_test_appropriate_installation()){ return "<p>OOPS you didn't configure your module correctly</p>"; } return drupal_get_form("mysettings_form_id"); } Jamie Holly Chris Johnson wrote:

There has to be a better solution than a form_initialize() hook. This is not criticism directed at you, Sheryl. But I think you've got a use case that should be addressed, assuming there is not an existing way to do it. I may well be ignorant of the proper, Drupal-ish way of handling this situation.

..chris

On Wed, Jan 21, 2009 at 4:12 PM, Sheryl (Permutations Software) <sheryl@permutations.com> wrote:

...

I figured out what the module code was trying to do by creating the error. It's actually not well implemented even in Drupal 5, but I don't know if there is a function in Drupal to handle the case.

When the administration form for the module is first loaded, the code checks to see if the module has been correctly installed. If it hasn't, it displays an error message at the top of the form. It attributes the error to the submit button just as a convenience. But the user still can see and submit the form. Ideally, there would be a form initialization function that checked that all was well before the form was even displayed. If all was not well, the user would see the error message, but no admin form.

I don't see a _form_initialize function anywhere in Drupal. Is it there somewhere and I missed it? If not, it might be a good thing to add.

In the meantime, how do I get the name of the submit button so I can use the same technique the module is currently using, but rewritten for Drupal 6? The button is not explicitly defined anywhere in the code - it must be using defaults. Also, according to the Drupal 6 docs, the name for buttons assigned by the system is 'op' - suggesting that the existing code is already correct:

http://api.drupal.org/api/file/developer/topics/forms_api_reference.html

The following is a list of default values which do not need to be set (found in system_elements):

button #name = 'op' #button_type = 'submit' #executes_submit_callback = FALSE #ahah['event'] = 'click' -------------------------------------

Thus this statement is exactly correct for what I want to do, even in Drupal 6:

form_set_error('op', 'error text');

Am I missing something here?

-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jakob Petsovits Sent: Wednesday, January 21, 2009 2:09 PM To: development@drupal.org Subject: Re: [development] converting a module from Drupal 5 to Drupal 6

On Wednesday, 21. January 2009, Steven Jones wrote:

...

Use form_set_error (http://api.drupal.org/api/function/form_set_error/6) and call it with the first parameter as 'NULL', then the error will be set on the form as a whole, not an individual element.

form_set_error() encloses the error assignment in this if-condition:

if (isset($name) && !isset($form[$name])) { (...set the form error...) }

which means when the first parameter ($name) is NULL then no error will be set. It seems you need to set the error for any of your form elements, presumably

the submit button in your case was used because the submit button was the only element that's remotely suitable for that error.

You might use the actual submit button as error target in Drupal 6 (...I think that should work) by doing a form_set_error('mybuttonname', t('message')) or - alternatively, same effect - form_error($form['mybuttonname'], t('message')).

Cheers, Jakob

Quoting "Sheryl (Permutations Software)" <sheryl@permutations.com>:

In the meantime, how do I get the name of the submit button so I can use the same technique the module is currently using, but rewritten for Drupal 6?

Based on the below the button name is 'op'.

The button is not explicitly defined anywhere in the code - it must be using defaults. Also, according to the Drupal 6 docs, the name for buttons assigned by the system is 'op' - suggesting that the existing code is already correct:

http://api.drupal.org/api/file/developer/topics/forms_api_reference.html

The following is a list of default values which do not need to be set (found in system_elements):

button #name = 'op' #button_type = 'submit' #executes_submit_callback = FALSE #ahah['event'] = 'click' -------------------------------------

Thus this statement is exactly correct for what I want to do, even in Drupal 6:

form_set_error('op', 'error text');

Am I missing something here?

Deadwood has given you a false positive; ignore the warning. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

If I have asked about this in the wrong place, could you tell me where I should report the problem? It mentioned in the CVS tutorials that there's a CVS webmaster who can fix problems, but I don't know how to contact that person. Thanks. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Sheryl (Permutations Software) Sent: Friday, January 23, 2009 11:23 AM To: development@drupal.org Subject: [development] how to fix a cvs branching error? I made an error when I created the branch for the 6.x version of the phpFreeChat module, and I need advice on how to fix it. FYI... I'm using TortoiseCVS. I can log in on the command line if absolutely necessary, but I will need "type this" style instructions because I'm a CVS novice - which is why I made the mistake in the first place. Here's the problem... I created a branch called DRUPAL-6--1. And then (here's the mistake) before committing the new files I created a tag called DRUPAL-6--1-0. I then committed the new files to the branch and went to the project page to release the new version. I had a choice between the new branch or the new tag, which confused me. I chose the tag (wrong). This resulted in the 5.x-1.3 files (latest version of DRUPAL-5 branch) being placed in the DRUPAL-6--1-0 download. Someone reported the problem and I realized my mistake. So I created a new tag called DRUPAL-6--1.1 and released this. That worked, since this time the tag was created AFTER uploading the new files to the DRUPAL-6--1 branch. On the Drupal site, all appears well. 6.x-1.1 is shown as the current recommended release and it has the correct files. BUT... if you install the module, go to the Drupal admin panel, and select Reports-Updates, it says that phpfreechat 6.x-1.0 is the recommended version, with the warning that "no available releases are found". I don't have the faintest idea why it says that or how to fix it. Please advice. - Sheryl

Stewart Robinson wrote:

Op means different things in different places, or at least its values do. What function does your copied code come from and do you know the value of op?

It's related to the admin form. In phpfreechat.module there is this function: function phpfreechat_settings() { return system_settings_form(_phpfreechat_settings()); } The mystery code is in the function _phpfreechat_settings()in phpfreechat.inc. It's the first three statements. I can't figure out what $form_values['op'] refers to, or what it means if the value is not empty, and I can't figure out how to rewrite form_set_error('op', 'error message') in case of error - I don't see what the error conditions tested have to do with buttons or any other control in the admin form. I have spent hours digging through Drupal docs trying to figure this out - docs for the Drupal 5 API, docs for the changes between Drupal 5 and Drupal 6. I'm not asking for links to these articles. I have them. I'm asking for someone to please give me a substantive answer to these two small questions: (1) What does $form_values['op'] refer to, and what does it mean if the value is not empty. (And how does Drupal 6 code this.) (2) How do I rewrite form_set_error('op', 'error message') for Drupal 6 when it's being set in response to a condition that has nothing at all to do with controls in the form? Thanks. - Sheryl On 1/21/09, Sheryl (Permutations Software) <sheryl@permutations.com> wrote:

I'm converting a module from Drupal 5 to Drupal 6, and I'm having a very hard time understanding the change in the use of 'op'. I can't figure out how I need to change my code. There are these lines.

if (!empty($form_values['op'])) { _phpfreechat_clear_cache(); _phpfreechat_clear_cookies(); } if (!_phpfreechat_check_install()) { form_set_error('op', _phpfreechat_not_found()); } if (!_phpfreechat_check_files()) { form_set_error('op', t('Unable to create data folders for phpfreechat.')); }

I took this module over from someone else, so I don't fully understand the use of 'op' here to begin with. Not understanding what it's doing makes it very hard to rewrite. I've spent the last two hours on the Drupal site trying to figure it out and I'm boggled. All I can tell is that 'op' was the default name of buttons in Drupal 5, but I still can't figure out what's being tested in these "if" statements or how I need to rewrite them for Drupal 6. Any guidance you can give me would be greatly appreciated!

- Sheryl

On Wed, Jan 21, 2009 at 11:56 AM, Sheryl (Permutations Software) <sheryl@permutations.com> ...r how I need to rewrite them for

Drupal 6. Any guidance you can give me would be greatly appreciated!

Did you try this ? http://drupal.org/project/deadwood http://drupal.org/project/coder -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/

Yes, I already did all the things you suggest. I would not have bothered the people on this list with my question if I hadn't already tried hard to find the answer on my own. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earnie Boyd Sent: Wednesday, January 21, 2009 9:57 AM To: development@drupal.org Subject: Re: [development] converting a module from Drupal 5 to Drupal 6 Quoting "sivaji j.g" <sivaji2009@gmail.com>:

On Wed, Jan 21, 2009 at 11:56 AM, Sheryl (Permutations Software) <sheryl@permutations.com> ...r how I need to rewrite them for

...

Drupal 6. Any guidance you can give me would be greatly appreciated!

Did you try this ?

http://drupal.org/project/deadwood

A start in the right direction. It doesn't do everything because it just doesn't know how. For instance you'll need to watch out for those ``if ($may_cache)'' and remove them even thought the deadwood removed the parameter in the goodwood version.

http://drupal.org/project/coder

Coder is a lint helper to give you suggested ideas of how well your code is formatted to the code standard for that Drupal version. Your module will look prettier but it doesn't help the functionality. You will also want http://drupal.org/project/schema on the version 5 side of your conversion if you have tables. The project/schema module can help on the version 6 side if you're developing a new table in say phpMyAdmin and now need to create the schema array for your .install file. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/

sivaji j.g wrote:

Did you try this ? http://drupal.org/project/deadwood http://drupal.org/project/coder

Yes. It was a warning in my code inserted by deadwood that alerted me to the 'op' problem in the first place. But I have been unable to fix it, for reasons previously stated. That's why I wrote to this list asking for help.