Project Templates cause 500 error when creating new project

Just upgraded to 7.14.2 and I can no longer apply project templates to projects.

The error is:

[18-Jan-2024 21:30:25 UTC] PHP Fatal error:  Uncaught Error: Call to a member function format() on bool in
Stack trace:
#0 Project->save(false)
#1 actionCreateRecord->set_record(Object(Project), Object(Project), Array, true)
#2 actionModifyRecord->run_action(Object(Project), Array, true)
#3 AOW_WorkFlow->run_actions(Object(Project), true)
#4 AOW_WorkFlow->run_bean_flows(Object(Project), 'after_save', '')
#5 LogicHook->process_hooks(Array, 'after_save', '')
#6 LogicHook->call_custom_logic('Project', 'after_save', '')
#7 SugarBean->call_custom_logic('after_save', '')
#8 SugarBean->save(false)
#9 Project->save(false)
#10 include_once('/home/pablostev...')
#11 SugarView->includeClassicFile('modules/Project...')
#12 ViewClassic->display()
#13 SugarView->process()
#14 SugarController->processView()
#15 SugarController->execute()
#16 SugarApplication->execute()
#17 {main}
  thrown in on line 625

The pertinent lines are: (625 is the last one):

                       $start_date = $count - 1;
                      $startdate = DateTime::createFromFormat('Y-m-d', $enddate_array[$start_date]);
                      $start = $startdate->format('Y-m-d');

I did some investigation and if the date fails, it returns false (therefore boolean) and then it fails 500 error.

Anyone else have some input on where to look to get to the bottom of this one? This is really stretching my PHP knowledge.

I mean can solve the error by an IF statement and get around the problem. Hoping someone with date troubleshooting experience can send me off in a direction.

Dates are complicated…

Exactly which PHP version did you have before, and which do you have now? Maybe some of those functions changed with the PHP upgrade, at least that would explain the difference in behavior. If so, there are likely sites online explaining what changes need to be made…

Thanks @pgr Im going to have another look today. I was on php 7.4 before. I checked the file on github and it hasn’t had changes for 8 months, so I think the problem has to be the difference in how 7.4 and 8.1 handles the error when the array value is null. Currently its outputting as boolean false which then cannot be converted to a date which then causes the 500. Im still not sure if the problem is that it is null or how the null is handed.

:point_up: this is actually an important part for debugging this… you can see how it happens with PHP 7.4, when it works, that would be helpful.

Then we can know if we need to look at the date functions, or if we only need to handle the returned null a bit better (which would be easier).

Ok I’ve reverted back to 7.4 and still get the error. So it has to be a change in the upgrade… grr that makes it harder. I’ve reviewed all the file changes on Github going back like a year and not seeing anything that really affects this (I think).

I’ve done a whole bunch of logging and the issue I think is definitively that the array is blank and thus can’t be converted to a date.

Fri Jan 19 14:41:11 2024 [27061][1][FATAL] enddate array count==1: Array
    [1] => 2024-01-24

Fri Jan 19 14:41:11 2024 [27061][1][FATAL] startdate array else: 1
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] enddate-startdate array else: 
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] Date string is empty or contains only whitespace.
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] startdate array else: 2
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] enddate-startdate array else: 
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] Date string is empty or contains only whitespace.
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] startdate array else: 3
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] enddate-startdate array else: 
Fri Jan 19 14:41:11 2024 [27061][1][FATAL] Date string is empty or contains only whitespace.

It seems after the first iteration the enddate array is not getting populated.

And isn’t PHP giving some other log message in php_errors.log, just before the FATAL?

If there was some warning during the date calls, that might be helpful

OK I think I got to the bottom of it!!!

There is this change: Run rector on modules folder · salesagility/SuiteCRM@9aff707 · GitHub

Where $enddate_array = []; is supposed to be added at line 330, however, it’s actually added in line 613 when you look at the current file. (I think) because it’s not on line 330. This causes the the array to clear after the first loop.

Commenting out line 613 solves the problem. I’m going to test placing it at line 330 where I think it’s supposed to go.


Should I open up a Github issue on this one?

If we don’t have PR/issue on the GitHub. You should definitely open a new one. :melting_face:

So initializing the array at line 330 causes no issues and removing it from line 613 solves the problem. So my conclusion is that somehow that particular push from Github put the change on the wrong line??? Not sure how that could happen.

Could you please share code here too?

Ok the fix is in!

Yes, it’s in SuiteCRM 8 as well. I haven’t checked the actual code, but just tested a project creation in my test 8 install from a template and same result 500 error.

@pstevens Important, you have to put the number sign (‘#’) immediately next to (no spaces in between) the number of the Issue it fixes. Like this: Fix #10321. When you don’t (Fix# 10321), then github fails to associate the Fix with the Issue !! Luckily, you get another chance, github lets you edit it.

Ok will do. Thanks @chris001 for all the coaching around this. I really appreciate it. I don’t use Github everyday and I’m mostly self taught so it’s super helpful.

Hi all,

I think I have read somewhere on the SuiteCRM website that we could upvote a PR. So, it will get more priority to fix.

If anyone know, please share here. :desktop_computer: :keyboard: :computer_mouse: