Unable to load custom logic file:

custom/include/social/hooks.php

Have just upgraded to 7.7.9, but reviewing log shows it has existed through several upgrades (wish I had known about the log sooner), at least from 7.5.5. Response time when opening and importing already downloaded email messages is poor (20+ seconds), but very good in all other modules.

Full message that displays three times every five minutes after login and functions like previewing email message:

Sun Jan 29 13:26:11 2017 [5108][1e48ace2-faf1-738e-45b3-5575b14f1ad4][ERROR] Unable to load custom logic file: custom/include/social/hooks.php.

This hooks.php file does not exist and the ‘social’ folder only contains ‘twitter’ and ‘facebook’ folders. I haven’t made any configuration changes to social media modules nor hooks. I suspect this is an unresolved reference that can either be commented out or resolved by creating the referenced file, but I don’t know where to start.

Any help will be greatly appreciated.

Have you tried searching through your php files to see if you can find the reference? Use any text editor or simply grep from the command line.

Found that SuiteCRM/custom/modules/logic_hooks.php contained $hook_array[‘after_ui_frame’][] = Array(1, ‘Load Social JS’, ‘custom/include/social/hooks.php’,‘hooks’, ‘load_js’);.

Commented it out, error message no longer appeared, however, a new one began appearing at each email message handling task,
Mon Jan 30 13:13:40 2017 [15206][1e48ace2-faf1-738e-45b3-5575b14f1ad4][ERROR] Unable to load custom logic file: custom/modules/Contacts/ContactsJjwg_MapsLogicHook.php .

Found and removed two references from /var/www/html/SuiteCRM/custom/modules/Contacts/logic_hooks.php , again eliminated the error message but then generated Mon Jan 30 14:36:18 2017 [1482][1e48ace2-faf1-738e-45b3-5575b14f1ad4][ERROR] Unable to load custom logic file: ContactsJjwg_MapsLogicHook .

No improvement on excruciatingly long email handling response time so I think I’m barking up the wrong tree - removing the references instead of resolving them. I think I should uncomment the above references back in and create the hook.php files being referenced but I don’t have any experience with this.

I think there were a few problems with an upgrade a few months back, and some people (also happened to me) were left with inconsistent hook definitions.

If you read this https://github.com/salesagility/SuiteCRM/issues/2587 you’ll get an idea of the problem. It also includes extensive lists of what files should be there, so it might help you sort things out in your installation.

1 Like

I was able to resolve this message by:

  1. Obtaining a copy of /custom/include/social/hooks.php from the 7.2.2 full install set and copying it into the same local folder.
  2. Restoring my original uncommented-out /custom/modules/logic_hooks.php.

This leaves me with one error message that I describe in a new topic created Feb 1-17: [ERROR] Index doesn’t exists in the specified directory.

I’m glad you got things (mostly) working, but I wouldn’t be too happy with your solution, if I were you…

It works because you matched your hook definitions with the hooks present or absent from your system, but you did that with files from before 7.5, which is when things got changed around. You now have a partially upgraded system, not very consistent, it could cause more trouble in the future.

It would be much better if you could get things the way they should really be, post v.7.5. You would do this by following the information I left on that Github page, but perhaps you need more information, like “what is inside /custom/modules/logic_hooks.php in a fresh install?” or something similar. I can post file contents here, if you need.

Just for information, do you have any hooks customized by yourself? Or are you just trying to get the basic SuiteCRM hooks to work?

You’re correct that I wasn’t happy with the solution, and less so now that a previously working campaign is also failing with numerous new error messages. I’m now trying to decide how to present these without seeming like I expect someone else to figure this out for me.
And no, I haven’t any customized hooks. It’s disappointing that one of the previous updates was written to obliterate the custom folder contents and not restoring them post-upgrade. I understand it is our responsibility to do so but I had less of an understanding of the structure several upgrades ago and thought the positive post-upgrarde integrity check was reliable.

Actual post-install custom folder tree contents would be helpful. I need to build a beta environment but I run a small business and the finding the time to do that is tough.
Thanks for your help.

The faulty upgrade is not completely faulty and careless; it just seems to be problematic in a handful of cases. It doesn’t touch what is already there in custom directory, except what belongs to the SalesAgility modules, which it moves tho a new location and (supposedly) references correctly in hook definition files.

In my post on Github (link above) the first long listing I give is exactly what you ask for, a complete list of the custom folder right after a fresh install. Good luck.

pgr:
I reviewd the 7.7.6 folder/file list you provided and identified the following as not found in my active 7.7.9 :

  1. ./custom/include/tabConfig.php
  2. ./custom/modules/Home/dashlets.php
  3. ./custom/modules/Projects/
  4. ./custom/modules/Projects/logic_hooks.php

Existing in mine but not showing in your listing:
5) ./custom/modules/contacts/ (./custom/modules/Contacts/ exists)

Searching at ./SuiteCRM/ I have these:

  1. /include/
  2. /modules/Home/
  3. /modules/Project/
  4. but not /modules/Project/logic_hooks.php

Do you think I can copy 1, 2 and 3 into /custom/ from ./SuiteCRM/ ? If yes, should I search for 4 to do same?

While you’re there, please upvote the initial text on that issue, it’s a small step to getting it taken care of.

You should look for the files you need here (version 7.7.9 shouldn’t be too different from the current code).

The ones that you don’t find there, are the ones created by the installer. If you can narrow it down to just a few, you can try asking me for the contents of those files : -) I have a Virtual Machine sitting somewhere with a fresh installation, I can try firing it up and retrieving the files.

Meanwhile, I’m not sure what you mean by ./SuiteCRM/. I’d like to understand better what you wrote in your post.

I responded to your Feb 6 post but see that it didn’t save :o( and don’t have the text I entered. What I can (re-)tell you is that I created an account at GitHub and upvoted the initial issue.

I reviewed the files at the second Github you posted and determined it contained two files I don’t have in my installation - dashlets.php and tabConfig.php. I have not yet but do you feel I am safe to copy them in? I suppose I can pull them back if it gets worse. There was also one more whose name I can’t remember so I’ll need to compare both trees again to be sure.

Finally, by ./SuiteCRM/ I just mean at the root of SuiteCRM. The absolute path is /var/www/html/SuiteCRM/ .

Thanks.

Hi, sorry you lost the text of your post, that can be pretty annoying…

To up-vote the Github issues you need to do it on the first comment on the very top of the Issue, because that’s what counts when you sort the issues by most “+1” reactions, like this:
https://github.com/salesagility/SuiteCRM/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

About replacing the files, I would say it’s safe to try. Of course you should have a proper backup of the files you replace, and maybe a zip of everything so you can really check what was there before, in case you get confused later.

But you can start with just copying the appropriate files - that might fix it.

But don’t forget you might also have to go into the detail of which hooks are defined in which files. Checking file sizes might be a good way of getting quick clues on which files are different from the fresh install. This might seem like a lot of work but it doesn’t really have to be; if you follow the leads that the log errors give you, you should be able to get close to the source of problem easily.

Good luck.

I upvoted the issue at its top as you instructed.

Then from the GitHub source I copied into my installation at ./custom/ :
/include/tabConfig.php
/modules/Home/dashlets.php

The result was a ‘connection failure’ message following my sign-in attempt (unsuccessful).
I did not see ./modules/Projects/ logic_hooks.php at the GitHub source (this is also missing in mine), so perhaps I need it to resolve references involving the two files I had brought in? Any ideas where I can get a copy to try?

Here’s a zip with the entire SuiteCRM folder right after it’s freshly installed (version 7.7.9). I only removed config.php, config_override, and a few large libs that were just taking up space but are irrelevant to your issue.

https://dl.dropboxusercontent.com/u/8232796/installed.zip

I really don’t see any way those two files can get you a “connection failed” error. You must have something else going on there… anyway, good luck, I hope this helps.

pgr: Thanks a lot for the zip. I compared it to my installation and found a lot of discrepancies just in the \custom folder, for example \modules\Cases\Ext\Vardefs\vardefs.ext.php. I don’t know what to look for in the file contents’ differences. Some others just look to be self-referential, and I concluded that just replacing mine with those you sent me would be too dangerous.

I then reviewed the files mentioned in github.com/salesagility/SuiteCRM/issues/1007 and found that I had used an asterisk in the filename (now I understand) in -rwxrwxr-x 1 www-data www-data 20 Feb 27 03:00 segments.gen . I corrected this and have now gone a few hours without another occurrance of “Index doesn’t exists in the specified directory.”

However, I then got “File ‘modules/AOD_Index/Index/Index/segments_1’ is not readable.” GitHub/…1007 referred to segments_1uc (note the two additional name extension characters). I copied segments_1 in from your set, set the permissions etc., and it too has not returned.

But now I get "Field date_start expecting datetime format, but got value: " and “Unable to load related bean by id” after importing a downloaded email. There are hundreds of files with ‘date_start’ labels just in \custom alone.

I then created /var/log/php/php-scripts.log, gave its ownership to www-data:www-data and then pointed to it from /etc/php5/apache2/php.ini, hoping to capture php errors, restarted apache but not a byte has been written into it.

Pretty discouraged now.

I’m afraid you’re going off in too many directions at once. By pointing you to lists of files, and giving you a zip with the files from the fresh install, I didn’t mean that you should start copying things from one installation to another. Many things in SuiteCRM are automatically generated, and there is no need to copy these (in fact, it can be harmful). Copying should be kept to a minimum.

I think you should just be fixing the hook problem you had at the beginning. If you get into other problems, you have to stop and think what is the best strategy for those other problems.

One issue at a time:

  • ignore differences in files that are generated by SuiteCRM from others (on Quick Repair and Rebuild): things like /custom/modules//Ext/ and /custom/application/Ext/

  • the AOD Index, i.e, anything under modules/AOD_Index/Index/ will get recreated if that whole directory gets corrupted and needs to be deleted. But be warned, it can be a slow and disk-intensive process if you have a lot of data. Anyway, any files copied from a different installation will be totally meaningless and incoherent with your install.

  • make sure you understand the hook definition problem: how they are defined, how to tell if they were being loaded and called (examining the logs). You just need to get one or two specific hook references consistent with your files! Nothing more, nothing less.

Going forward: can you get back to where you were before you started copying files, so that you have only the initial error with the hook?

I decided that since I really need a beta environment for testing going forward, I should build a new one on another machine, stabilize it, import my data and make it production when clean. Then build a new SuiteCRM of the same VRM on the original box and use it for testing.

SuiteCRM 7.8.2 is now installed on Windows 10 Pro, mostly configured but not yet loaded. It’s clean except for one error that I will post in a new topic.

PGR: Thanks for all your help.

Sounds like a good strategy, good luck.