I can confirm that I neither changed nor removed the manifest.php file.
My reply was for @hevii-bubba sorry if I am adding to the confusion
@Turbo549 youāre not getting that error, are you? (The zip file is missing a manifest.php file. Cannot proceed.)
I had made no changes at all to that file, @pgr
Yes, but Iāve seen cases where people unzip, change some files, and zip again, but in the process they add another directory. Meaning, the manifest.php file that was previously at the root, appears inside a directory in the zip afterwards. That way, the manifest canāt be found.
I was just saying to check that, in case it was the problem.
@pgr, Iām not getting that error.
1 Like
I thought that perhaps the problem was due to the peculiarities of my compression software. So, I uncompressed both zips, made the change and recompressed on my Mac box as well as on the Linux box. Regardless of which box I attempted to upload the module from, the dialogue informed me that the manifest file wasnāt available.
I uncompressed again and found that it was indeed where it seems it should have been (at the root of the compressed file) since thatās where the original was located.
Howās it going with āfixingā the current patch and loading a replacement so that others who experience the same problem can finally move forward with their upgrade?
Based on how long this has been a problem without a resolution for many of us, Iām beginning to get the feeing that the folks at Sales Agility are sitting back and snickering at the frustration which some of us are experiencing.
Is this some sort of twisted attempt to have users āupgradeā to āpaid supportā?
Hi @hevii-bubba,
To zip your module with manifest.php in the root directoy, go into directory where manifest.php is located, then:
zip -r upgradepatch.zip LICENSE.txt manifest.php UpgradeWizard
To make sure that manifest.php really is in the root, test your zip file by
unzip -t upgradepatch.zip
and make sure it lists manifest.php as (without any directory):
testing: manifest.php
As mentioned in the github thread: if you already installed the module before, then change the version in the file manifest.php by changing the line:
'version' => '1.0',
to
'version' => '1.01',
Please note that multiple solutions have been suggested and it may not be straightforward for SA to decide on an effective fix. Your input on this is valuable.
1 Like
Hey folks! Will give this a go today, hopefully run into the issue and Iāll see what we can do,
Thanks, @jansiero. That did it for me 
Having also the blank wizard problem after upgrading my 7.8.3 version with upgrade 7.8.x-7.10.x I had success with this solution.
I used the upgrades from SourceFourge (https://sourceforge.net/projects/suitecrm/files/upgrades/) and first I updated to the last subversion of 7.8 with upgrade 7.8.x - 7.8.31, then to the last subversion of 7.9 et cetera.
Mayby a bit clumsy and timeconsuming, yet more time efficient than trying again and again with an upgrade that tries to do all but fails again and again.
OMG, Iāve been trying to get this fixed since last year.
I first installed the 1.0.1 patch, then install the latest update patch, that failed and resulted in the blank page. Then I deleted all the contents of upload/upgrades/* - reinstalled the 1.0.1 patch, then I did all the incremental updates one at a time, instead of just trying to use the latest update.
7.8.31 -> 7.9.x -> 7.10.28 -> 7.10.31
But not without some difficulty, I was seeing database failure messages due to SQL query errors.
Query Failed:CREATE INDEX idx_user_name ON users (user_name,is_group,status,last_name (30),first_name (30),id)::: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Incorrect syntax near '('.
Which required me to manually create the index, which also failed because the upgrade was deleting the index and trying to recreate it, but in my version of MSSQL, you donāt need or canāt use the (30) in the selection of the fields for the index, so I had to search for, and change the array in the following files:
cache/upgrades/temp/xxxxxxx/scripts/files_to_add_post/modules/Users/vardefs.php
cache/modules/Users/Uservardefs.php
cache/modules/Employees/Employeevardefs.php
`array (
'name' => 'idx_user_name',
'type' => 'index',
'fields' =>
array (
0 => 'user_name',
1 => 'is_group',
2 => 'status',
3 => 'last_name (30)',
4 => 'first_name (30)',
5 => 'id',
),`
And remove the ā(30)ā changing it to:
`array (
'name' => 'idx_user_name',
'type' => 'index',
'fields' =>
array (
0 => 'user_name',
1 => 'is_group',
2 => 'status',
3 => 'last_name',
4 => 'first_name',
5 => 'id',
),`
This will of course will result in some other SQL warnings, but not failures - and the index gets created and gets you past the error.
After many days of trying to resolve this problem, I have determined that the fix is simply to ensure that the account you are using to upgrade (in my case, admin) is setup to use the default theme, SuiteP. I was using SuiteR which caused the loss of Next button functionality to Confirm the Update. Once I ran the upgrade using the SuiteP theme, all worked as expected. My upgrade was from 7.8.31 to 7.10.36 and then subsequent upgrade from 7.10.36 to 7.13.3. UMMV but this was the solution for me.
Dianna
1 Like