Zend folder populated with files with no code in them from SuiteCRM 7.11.8

Has anyone any idea why the Zend folder is now just populated with files with no code in them?

It’s been moved to “vendor”, handled by Composer.

https://github.com/salesagility/SuiteCRM/pull/7672

Exactly which “Zend” folder are you talking about (full path)?

This is to remove old files, hasn’t been merged yet: https://github.com/salesagility/SuiteCRM/pull/8094/files

I’m referring to the Zend folder in the root of the SuiteCRM site.
I don’t see a Zend folder under vendor in 7.11.10 by the way.
This stopped Opacus (CalDav) from working. Their code checks in /Zend and /vendor/Zend.

You’re right. Looking more closely at Composerify Zend by connorshea · Pull Request #7672 · salesagility/SuiteCRM · GitHub it seems it was reverted. The newest packages still have stuff under “/Zend” directory.

There are some packages unders “vendor/zf1/” but I’m not sure how complete that is supposed to be.

Your initial problem

isn’t happening in my installation - I see normal files. The upgrade package also contains normal files. So :huh:?

Just checked the upgrade file “SuiteCRM-Upgrade-7.11.x-to-7.11.10.zip” and the root folder has the broken Zend and no vendor/Zend

I don’t see that in the package. Maybe you can try re-downloading, and checking the MD5?

Already checked that.

Are you checking an upgrade package downloaded today, or earlier? I checked today. I wonder if it might have been changed (MD5 and all) after first being published?

I’m running out possible of explanations, after this we’re in the twilight zone :ohmy:

Working from the download page on suitecrm.com I have just downloaded the following and they all have the “broken” Zend folder.

7.11.x to 7.11.10 upgrade;
https://suitecrm.com/files/162/SuiteCRM-7.11-Upgrades/486/SuiteCRM-Upgrade-7.11.x-to-7.11.10.zip

7.11.10 clean install;
https://sourceforge.net/projects/suitecrm/files/SuiteCRM-7.11.10.zip/download

7.11.10 Source Code;
https://github.com/salesagility/SuiteCRM/archive/v7.11.10.zip

Ok, I see what you mean now. The files exist and something in them, but it’s just placeholders. Up 'til now I haven’t been opening the files so I wasn’t understanding what you were talking about. I thought I was supposed to be seeing empty dirs or zero-length files.

Sorry about that, my bad.

I don’t know what’s going on. I’ll ask the Product Team about this on Monday. My expectation is that the code that should be working would still be scattered in other places like modules/AOD_Index/Lib/Zend/Search/Lucene/ and similar.

Do you know which parts of Zend Opacus is trying to use?

@include_once ‘Zend/Http/Client.php’;
@include_once ‘vendor/Zend/Http/Client.php’;

So that’s in

vendor\zf1\zend-http\library\Zend\Http\client.php

which is really a weird directory, obviously, though that shouldn’t matter if composer’s “autoloader” does the work of finding it for you. So perhaps just removing the “includes” so they don’t give a fatal error could be enough - when the class gets instantiated, the autoloader should be able to do its job…

I’m a bit out of my depth here, I am not that familiar with this - so it’s just something to try

I don’t want to be altering the code of a third party plugin and having to maintain it.
Also I don’t know what else might be expecting Zend in the usual place.
So I just copied the Zend folder from 7.11.7

Can you please try with the Zend folder as is comes in the package, but with this fix added to our code?

I asked my colleague about your Opacus case and he said

It doesn’t use OAuth.

1 Like