Hi!
In a recently developed and published website, I ran into a problem with the scheduler module, which is driving me absolutely crazy. I'm hoping someone has experienced the same problem.
At node/add form I enter a publish and unpublish date. The scheduler format used is Y-m-d H:i:s
The dates are stored in the DB. Also the node will show up on the content > scheduled overview page.
So far so good.
Here's where the shit hits the fence. When editing this node the fields are empty. So when the user saves the node the stored values are overwritten by the empty fields. And the node won't be unpublished.
I'm using scheduler with date popup. But disabeling date popup and setting scheduler to a textfield hasn't had any results. When I take a var_dump of the value in scheduler_form_alter -> nodetype_form
$form['scheduler_settings']['publish_on'] = array(
'#type' => 'textfield',
'#title' => t('Publish on'),
'#maxlength' => 25,
'#required' => $publishing_required,
'#default_value' => isset($defaults->publish_on) && $defaults->publish_on ? format_date($defaults->publish_on, 'custom', $internal_date_format) : 'test',
'#description' => $description_format.$description_blank,
);
}
The #default_value contains the correct date format. When I add #value to the form with the #default_value the fields are correct.
Can anybody help me why the #value of this fields stay empty?
Thank you.
Cheers,
Eric
Comments
Comment #1
jonathan1055 CreditAttribution: jonathan1055 commentedHello,
This does not sound like a problem solely caused by scheduler otherwise plenty of other people would have noticed it. Maybe another module of yours is altering the form with a hook_form_alter. Admittedly this should not cause a problem, so I'm not saying that scheudler isn't at fault. But it is working fine for me and many other users, so it must be some interaction with another module of yours.
Can you list all the hook_form_alter functions which your site knows about, then we can check which it might be.
Jonathan
Comment #2
jonathan1055 CreditAttribution: jonathan1055 commentedI forgot to say, can you show us what is in the $defaults object? If you have devel module, just add dpm($defaults) and get a screen grab, or if not, add
drupal_set_message('<pre>' . print_r($defaults, true) . '</pre>')
or something like that.Comment #3
ericclaeren CreditAttribution: ericclaeren commentedHi Jonathan,
Thanks for you quick reply. I'm also guessing that it's another module, but the problem is that I have really no idea which one. We have used hook_alter_form in a custom module, but there's an if statement that validates that it has to be an ubercart product and we don't use scheduler on ubercart product type nodes.
The website is quite complex and has around 50/60 contributed modules installed :S
In our back-end theme (modified garland), scheduler_form_alter is being called three times:
#search_theme_form
#news_node_form
#uc_multiprice_region_form
The last one is a custom module which is a block. I have disabled this block to exclude this form from this page and this hasn't had any effect on scheduler.
The var_dump of $defaults on the bottom of scheduler_form_alter gives me the following result. (Which looks fine by me).
Scheduler is used with vertical tabs, but excluding this fieldset from vertical tabs also had no result.
Thank you very much for your help.
Comment #4
jonathan1055 CreditAttribution: jonathan1055 commentedOK, good to see that $defaults is correct. I just want to make sure I know exactly the problem you are getting. When you view the generated source code on the node edit form, what do you get in the scheduler edit fields? In a clean D6 set-up, for unpublish, with vertical field tabs and text entry not pop-up I get:
Do you get nothing in the value=" " string, whereas in scheduler_form_alter() the value of $form['scheduler_settings']['publish_on']['#default_value'] is set correctly as a formatted text string?
If you have the devel module you can get a list of every function known to the system, so can find all the hook_form_alter() ones. Also have you checked if this happens on all node types? You might have some hook_form_NODETYPE_node_form_alter() functions too, which only come into effect on specific node types.
Jonathan
Comment #5
ericclaeren CreditAttribution: ericclaeren commentedThanks for your time and help Jonathan, It's very much appreciated!
The #default_value of $form['scheduler_settings']['publish_on'] returns the following 2011-05-26 01:57:17
Which seem to look fine. Weird right?
Just out of curiosity, why is the value save as #default_value and not just #value.
When add #value to the array the value is visible in the form. I'm just starting to understand module and form api and don't know the difference between the two.
There are a lot of form alters probably around 100/150 or so :S
But when I print $form_id on scheduler_form_alter only these three are shown:
#search_theme_form
#news_node_form
#uc_multiprice_region_form
Is it possible that another form_alter is breaking up scheduler?
Thanks Jonathan.
Comment #6
jonathan1055 CreditAttribution: jonathan1055 commentedI maybe asked too many questions in my last post. My first question is important. If you view the source code of your generated page, do you see anything like my example? Could you paste the html to show us here?
Comment #7
ericclaeren CreditAttribution: ericclaeren commentedHi, sorry I forgot to paste the source code, it's the same as your's but the value is empty.
What I don't get is that, when I var_dump($form['scheduler_settings']['publish_on']) I get 2011-05-26 01:57:17, which is a valid output. But the #default_value isn't set as #value.
Thanks!
Comment #8
jonathan1055 CreditAttribution: jonathan1055 commentedTo state the obvious, there is a long way between defining your form with #default_value and the html being generated with a value="" attribute. Along that route somewhere the form builder process is probably doing the right thing with the scheduler form elements and then some other process is messing it up. That is what we are trying to find out.
You talk in several of your posts about #value - are you actually manipulating the form elements directly in some way?
Jonathan
Comment #9
ericclaeren CreditAttribution: ericclaeren commentedHi Jonathan,
Yeah when I change the form #default_value to #value, the fields will contain the date.
Like this.
Thanks for helping, do you know if there's any possibility (function or magical trick) to see which function is altering the #default_value when the form is being processed?
Cheers!
Comment #10
BioALIEN CreditAttribution: BioALIEN commentedI would just like to chime in and say I am also experiencing a similar issue to this one. Have you found a solution to this?
I'm happy to help if you need debug info from me to backup your findings.
Comment #11
ericclaeren CreditAttribution: ericclaeren commentedStill searching for a solution for this issue, we have this problem on a very large project, with 50/60 contrib modules. (Lot's of ubercart add-ons). Unfortunately I still haven't been able to locate the problem.
Seems like the #default_value is set empty by another process.
Comment #12
jonathan1055 CreditAttribution: jonathan1055 commentedTo dreamlabs in #9, why are you setting #value in the form?
To BioAlian in #10, are you doing anything with #value in any of your custom code too?
Comment #13
jonathan1055 CreditAttribution: jonathan1055 commentedSorry, I think I mis-understood your post in #9. You were using #value temporarily to show it does work, but does not work when it has #default_value. Is that what you meant?
Comment #14
ericclaeren CreditAttribution: ericclaeren commentedYes that is correct, I just changed it to see if the value would be set. And it strangely did.
Comment #15
ericclaeren CreditAttribution: ericclaeren commentedHi Jonathan,
Do you have any ideas left why this problem occurs? I am a bit stuck.
Comment #16
jonathan1055 CreditAttribution: jonathan1055 commentedBeen away on holiday, hence delay.
I wonder if BioAlian who posted in #10 could list their contrib modules. Then maybe you could see which one coincide with your list. I can then reject any which I have and do not cause the problem, and that might leave a small enough set to check. Worth a try?
But it would be very strange for another module to specifically alter the scheduler fieldset, so maybe we should also start thinking about what module could interfere with the general form-building process.
Comment #17
sk33lz CreditAttribution: sk33lz commentedI also have the same issue as others in this thread, and have never had issues with any fields dropping their values on my site before. I have even tried disabling several modules that remotely might have altered my form and it still happens.
Comment #18
jonathan1055 CreditAttribution: jonathan1055 commentedI'm working on this right now, but cannot replicate it yet. I may post some code here which you can insert.
Are you working on the 1.8 version or a later dev release? Check the file scheduler.info for details.
Comment #19
ericclaeren CreditAttribution: ericclaeren commentedHi Jonathan,
Any news? I'm using version = "6.x-1.8".
Thanks!
Comment #20
ericclaeren CreditAttribution: ericclaeren commentedI have installed the latest dev version, stil no date. I just spend 3 hours outputting vars with no result. My thoughts; the default_value is set, but when de DB retreives the values and the format doesn't matches, can it be that it bypasses the default_value? This is driving me nuts.
Comment #21
jonathan1055 CreditAttribution: jonathan1055 commentedHello Dreamlabs,
Could you post here the code and the results of your output vars - it must show that somewhere the value is being dropped. Then maybe BioAlian and sk33lz can also run it.
As I've said before I cannot replicate this problem, so any assitance in showing me what you have will help.
Comment #22
szy CreditAttribution: szy commented@Dreamlabs, do I have a problem like yours:
-> #1357134: Rights problem? Different effect with manual and automatic import
There are nodes imported with dates for Scheduler, which
get empty after automatic import.
Szy.
--
Warszawa | Cycling in Fjord Norway
Comment #23
ericclaeren CreditAttribution: ericclaeren commentedHi!
I apologize for my late response. I switched jobs and things got a bit hectic. Unfortunately I don't have access to the source code of this project anymore.
I know the guy, who is working on this particular project, I will send this topic to him, to check If he still has problems with scheduler.
Cheers,
Comment #24
gozoliet CreditAttribution: gozoliet commentedNot sure if similar - can add nodes with publish_on info, but when editing, the publish_on date on the form changes to the current date() (And time), which screws people up if they don't catch it.
The publishing is working fine, as long as someone doesn't edit the node and changes the date/time.
scheduler (Array, 4 elements)
publish_on (String, 10 characters ) 1333857600
unpublish_on (String, 1 characters ) 0
published (String, 29 characters ) Sunday, April 8, 2012 - 00:00
unpublished (NULL)
Edit: #default_value is being set correctly right to the end of scheduler.module, so I can only assume it's a Date Popup issue. Still digging.
Edit Edit: Probably not a related issue. My issue is related to Date module requiring >= PHP 5.2. This site is running on 5.1.x, which doesn't have DateTime. Commenting out the class check in first lines of date_format_date on line 710-712 of date_api.module is a temporary fix for this specific issue, though certianly that will have other effects.
Comment #25
howdytom CreditAttribution: howdytom commentedI've had the same empty fields issue. As I found this was caused by a false trigger setting and to 2 orphaned actions. Be sure remove orphaned actions. I hope this helps.
Comment #26
anonymous07 CreditAttribution: anonymous07 commented+1 for the empty unpublish_on field issue.
Here is how to remove "orphaned actions"
Comment #27
ShedPhotons CreditAttribution: ShedPhotons commentedSame problem - blank entry fields, running OpenPublish distro on D 7.19 with Omega. #25 did not work. I could not tell if the other solutions were applicable.
Comment #28
szy CreditAttribution: szy commentedMy scheduling nodes come from import with Feeds module.
And the thing that helped me was changing the owner
of new, scheduled post from 'Anonynous' (or non-admin)
to admin. In the importer settings, of course.
So, it was kind of rights thing.
Szy.
Comment #29
jonathan1055 CreditAttribution: jonathan1055 commentedI'm closing this issue as 'cannot reproduce'.
There obviously was some kind of difficulty which we discussed from #1 to #21 without being able to replicate it. Then new users chipped in on #22, #24, #25 and #27. The error in #22 was caused by another module and I suspect that to be the case with the others too.
If anyone can point to the fault in Scheduler then please open a new issue, as this one has become too difuse.
For reference, there is also a similarly named issued raised in the 7.x queue #1453570: fields empty on node edit form
Thanks for your time on contributing to the discussion. Sorry we found no solution - but that's because we found no problem :-)
Jonathan
Comment #30
nicholas.alipaz CreditAttribution: nicholas.alipaz commented#1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue that might be the problem, I bet everyone is on PHP 5.4.
Comment #31
jonathan1055 CreditAttribution: jonathan1055 commentedHi Nicholas,
Thanks for that link, useful to know. I am on 5.3 locally where I did the testing so would not have seen the problem. Reading that issuse, looking at the patches in #8 and #19, the php 5.3 to 5.4 change seemed to give different results for empty() when using nested arrays. The comment in #7 is useful.
However, the original person who reported the problem said that they had also tried disabling date-popup to use the normal date field:
So it may have been the php version, would need more checking. If any of the people above who had the problem would like to check this, please report back on what they find.
Thanks
Jonathan
Comment #32
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedI can confirm that we had a site running fine on PHP 5.3 and just upgraded to 5.4 and the fields are now empty on edit.
Comment #33
jonathan1055 CreditAttribution: jonathan1055 commentedThanks for the feedback. Just so we can decide whether we need to re-open this issue, can you give a few more details please?
Comment #34
interestingaftermath CreditAttribution: interestingaftermath commentedI can confirm this is an issue after upgrading to the latest Date and Scheduler modules. The previously installed versions that worked as intended were Date 6.x-2.8 and Scheduler 6.x-1.8.
To answer the questions in #33:
I am going to rollback to the previous versions to try and track down which module it is.
To respond to the post where this issue was closed, these nodes were not recently imported. The only change has been the update of the Date and Scheduler module.
EDIT: This patch fixed this issue https://drupal.org/comment/7208980#comment-7208980
Comment #35
jonathan1055 CreditAttribution: jonathan1055 commentedThanks for the info. I've just done a quick compare of Scheduler 6.x-1.8 to 1.9 and I don't think there are any changes which would affect this. I suggest to try putting date module back to 6.x-2.8 first, and see if that improves things.
Jonathan
Comment #36
interestingaftermath CreditAttribution: interestingaftermath commented#34 is fixed by this patch: https://drupal.org/comment/7208980#comment-7208980
Comment #37
jonathan1055 CreditAttribution: jonathan1055 commentedThanks for that. The issue link is #1808416: Date showing on node view - not showing on node edit - PHP 5.4 issue and the patch is in #19
Comment #38
nicholas.alipaz CreditAttribution: nicholas.alipaz commentedSo if my understanding is correct, the fix is to upgrade Date module to a 6.x-2.x version later than Sept 26, 2013. Just thought I would add that here for anyone else who runs into the issue.