Want drupal.org to show dev shapshot but not "released" for D7 version of module
Good evening! I've looked at the online docs but am still a little ambiguous. I have a module that I've ported to the latest snapshot of Drupal 7; my module's most recent previous version is for D6. It's "working" but not "finished" yet in the D7 version. I'd like to CVS tag it in such a way that drupal.org will show the D7 version as a nightly development snapshot, as I progress toward an official release. It looks to me as if what I want is "cvs tag -b DRUPAL-7--1" for the development branch, then make a drupal.org release for that tag. If I recall, that sticky-tag release node on d.o will track daily changes. But since we're talking about a sticky tag, I want to be sure. I know how to do the official releases for beta and production with non-sticky tags, but it's been a while since I did one of these. Thanks for any reminders someone might care to post. Scott -- Syscrusher <syscrusher@4th.com>
On Fri, 2009-01-16 at 21:56 -0500, Syscrusher wrote:
I've looked at the online docs but am still a little ambiguous. I have a module that I've ported to the latest snapshot of Drupal 7; my module's most recent previous version is for D6.
It's "working" but not "finished" yet in the D7 version. I'd like to CVS tag it in such a way that drupal.org will show the D7 version as a nightly development snapshot, as I progress toward an official release.
It looks to me as if what I want is "cvs tag -b DRUPAL-7--1" for the development branch, then make a drupal.org release for that tag.
I found the answer elsewhere in the online docs...please disregard this question. Scott -- Syscrusher <syscrusher@4th.com>
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
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
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
Steve Jones wrote:
This is clearly in either a form _submit or _validate handler, so you'll want to read, and understand:
I already read it - multiple times - and it didn't help. I wouldn't have written to this list for help if I hadn't first tried to figure it out on my own and read all the relevant docs. - Sheryl -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Sheryl (Permutations Software) Sent: Wednesday, January 21, 2009 1:26 AM To: development@drupal.org Subject: [development] converting a module from Drupal 5 to Drupal 6 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 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
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
$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
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
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
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
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
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
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
I'll do //drupal_get_form('my_form'); function my_form() { Â if (everything_is_ok()) { Â Â Â $form = ... Â Â Â ... Â Â Â return $form; Â } Â else { Â Â drupal_set_message("something bad happened."); Â Â return array(); Â } } --- On Wed, 1/21/09, Chris Johnson <cxjohnson@gmail.com> wrote: From: Chris Johnson <cxjohnson@gmail.com> Subject: Re: [development] a "form_initialize" function? (was "converting a module from Drupal 5 to Drupal 6") To: development@drupal.org Date: Wednesday, January 21, 2009, 3:40 PM 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/
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
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
You can't fix this yourself if you've already created a release from the tag. Try http://drupal.org/project/webmasters for help. On Jan 23, 2009, at 3:41 PM, Sheryl (Permutations Software) wrote:
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
Quoting "Sheryl (Permutations Software)" <sheryl@permutations.com>:
(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?
When I'm debugging forms to understand the structures I use something like drupal_set_message('<pre>' . print_r($form_values, TRUE) . '</pre>') so I can see the contents of the arguments in the callback functions. The first argument of form_set_error should match the form element name being flagged with an error and is used in the form validate function. You might be able to rewrite the form_set_error as ``form_set_error('', 'error message')'' depending on what you need. Also, take the deadwood comments with a grain of salt because the comment could be a false positive based on regular expressions. Deadwood only gives a starting point, it doesn't do the whole job. http://api.drupal.org/api/function/form_set_error/6 http://api.drupal.org/api/file/developer/topics/forms_api.html HTH, -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.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 http://drupal.org/project/coder -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/
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 ?
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.
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/
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 ?
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.
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/
I think 'op' is simply the arbitrary identifier of the element being validated. form_set_error() marks the element on the form with styling (typically appears in red, or with a red asterisk or a red background) when in error, e.g. a required element was left blank. ..chris On Wed, Jan 21, 2009 at 10:57 AM, Sheryl (Permutations Software) <sheryl@permutations.com> wrote:
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 ?
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.
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.
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.
participants (12)
-
Chris Johnson -
Darren Oh -
Earnie Boyd -
Jakob Petsovits -
Jamie Holly -
Michael Prasuhn -
Sheryl (Permutations Software) -
sivaji j.g -
Steven Jones -
Stewart Robinson -
Syscrusher -
yi yang