Yetiforcecrm: Testing the Update package to 3.41427 and get white screen

Created on 15 Jan 2017  Â·  58Comments  Â·  Source: YetiForceCompany/YetiForceCRM

Hi,

I have tried to use the update for 3.4 to 3.4.1427 here https://github.com/YetiForceCompany/UpdatePackages/tree/developer/YetiForce%20CRM%203.x.x

When I run the update it produces the white screen. Is this because it now requires PHP 7x?

I also tried with a clean install of 3.4 - same problem.

❌ ignored 🐛 bug

All 58 comments

Is this because it now requires PHP 7x? [NO]

After update my Dev environment have this error and never worked again.

error

logs.. logs.. ??

@mariuszkrzaczkowski I set debug file but not have any logs cached in cache/logs/*

/* +********************
* Logger
*
******************* /
// Enable saving logs to file. Values: false/true
'LOG_TO_FILE' => true,
// Enable displaying logs in debug console. Values: false/true
'LOG_TO_CONSOLE' => true,
// Enable saving logs profiling. Values: false/true^M
'LOG_TO_PROFILE' => true,^M
// Level of saved/displayed logs
// Examples: false,3,['error', 'warning', 'info', 'trace', 'profile'],
'LOG_LEVELS' => 3,
// Level of saved/displayed tracerts.
'LOG_TRACE_LEVEL' => 0,
// Display Main Debug Console
'DISPLAY_DEBUG_CONSOLE' => true,
// List of IP addresses allowed to display debug console^M
// Values: false = All IPS / '192.168.1.10' / ['192.168.1.10','192.168.1.11']^M
'DEBUG_CONSOLE_ALLOWED_IPS' => false,^M
// Stop the running process of the system if there is and error in sql query
'SQL_DIE_ON_ERROR' => false,
// Displays information about the tracking code when an error occurs. Available only with the active SQL_DIE_ON_ERROR = true
'DISPLAY_DEBUG_BACKTRACE' => false,
// Debug Viewer => cache/logs/viewer-debug.log
'DEBUG_VIEWER' => true,
// Display Smarty Debug Console
'DISPLAY_DEBUG_VIEWER' => true,
/
+********************
* Configure a user-defined error handler function
*
******************* /
'EXCEPTION_ERROR_HANDLER' => true,
// Save logs to file (cache/logs/errors.log)
'EXCEPTION_ERROR_TO_FILE' => true,
// Display errors
'EXCEPTION_ERROR_TO_SHOW' => true,
// Set the error reporting level. The parameter is either an integer representing a bit field, or named constants.
// https://secure.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
// All errors - E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
// Critical errors - E_ERROR | E_WARNING | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR
'EXCEPTION_ERROR_LEVEL' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED,
/
+*********************

This is apache error not YetiForce. First you should check apache logs.

@bpabiszczak All configuration and variables was are set correctly in my environment, before this update all environment was working great.

This update need other configuration? applied this requirements

https://yetiforce.com/en/implementer/installation-updates/103-web-server-requirements.html

Why you dont check apache logs?

I have the same http 500 error with update. When i use a other browser or clear the browsercache i become a permission error.
error
I checked all my logs, but found no error. The server run with all versions since yf3.0 and all updates.
Tomorrow i will repeat the update and check more things ...

On one server went ok, on other not, complaining of IdleTimeout:
[core:alert] /var/www/vhosts/xxxx.fi/test.xxxx.fi/.htaccess: IdleTimeout not allowed here

and after solving that
500 GET /cache/updates/initFinal.php HTTP/1.0

this is a strange behaviour on a clean install everything works as expected, Problems arise when you performing updates to newer versions using existing database.

Additionally looks like you guys are always wiping off existing database and perform clean install, can you advice if this is the procedure you guys use I believe many issue reported are caused by system update procedure

try to edit index.php type:
error_reporting(E_ALL);
ini_set('display_errors', 1);

then try to navigate to other pages I get this error

( ! ) Fatal error: Cannot redeclare class VTEntityData in /var/www/yeti_dev/html/include/events/VTEntityData.inc on line 15

tested on version : ver. 3.4.1490

me too

Hi,

I made a mistake of

  1. Not backing up
  2. Not creating test environment
  3. Using it on production server

A typical, "Young Admin" mentioned in Yetiforce developer guide/blog.

I got this issue when I use Update > Package Yetiforce Update Package 3.4.0_to_3.5.0_4Beta
Was currently using 3.4.0 + hotfix patch.

After the "I agree" i got blank page and the website stop loading. I started panicking and here is a few step I did to resolve it. So anyone out there, if you fall into my situation all hope is not lost.

I made a subdomain for my server and used YetiForceCRM-developer branch (latest) on Github because ultimately I still want to use it (I was impatient). I keep getting a 500-Internal Error. I figure it probably because of PHP7 requirement so changed to PHP7 and it manage to load but getting some
/vendor/composer line 67 error.

So it seem like I won't be able to use it.

I decided, let just try 3.4 again then. Delete my current files via File Manager, extract v3.4 files into server/website public_html again, refresh my website and I got the, "installation page".

Experience enough now I know what to do with the installation. I edit the PHP setting as required (because when you change PHP version, custom setting have to configure again, alternatively you can use File Manager and restore the backup), I recycle my MYSQL login, username, password, and risked using my current database. I also recycle my admin password from my first installation. Click next, Installation seem stall for a moment, I start panicking again.

Install complete and the page refreshed. The login page is available now, no more blank page. Look like I escaped death.

I tried to log in, Got this error "MYSQL Error unblock vtiger_loginhistory" something like that. Look like I still need to panic. I went into myPHPadmin, open the database, search for vtiger_loginhistory. Look for anything that mention the word "unblock", couldn't find any. Read the error again and it sound like this "unblock" column is missing, and it looking for a value of "0".

So I maximum the tree on the left side, click Columns > New > Enter the following
Name - Type - Length
unblock - Int - 5

Leave other blank/default, clicked save. I choose Length as 5 because I assume it won't need more than 5 characters (hope that true).

Refresh the page still got the error. Refreshed again or clicked back (I can't remember) and I see my Yetiforce Homepage. Finally! But I logged in with my Non-Admin account, hopefully this wasn't 1 time luck. I logged out and logged back into using Admin account. All good to go. Went back to myPHPadmin and it seem like the "unblock" column are "0" now. Yetiforce must have did some correction error. (thank you).

Right after that, I enable my CRON job, activate Backup in Admin Setting. And this this a lesson well learnt. I'll still want to play with the latest version because there is a bug in 3.4 that is quite a hindrance. Furthermore are some feature I want in v3.5.

With that all typed. I hope this will provide some insight for other people who got stuck in same position as I am. Or is about to. Most important of all, please share your experience and resolution if you do ran into any. I might be in same situation as you are (in the future).

Thank you.

@ldgbc

thanks for sharing that. I was luck in that I download safe copies of both the folder and mysql database so could reinstall quickly.

It doesn't look like a 3.5 version is going to be released as it has way past the milestone date and there seems to be a 4.0 version out in a week or so.

Look like I celebrated too early. Although the Homepage and Setting/Admin page work. However all my other module: such as Contact, Account doesn't load.

It blank page when I try to view them. I learn how to enable logs in this post. https://github.com/YetiForceCompany/YetiForceCRM/issues/3619 thank to @rskrzypczak and manage to see these error when I open the page.

LBL_SQL_ERROR
LBL_ERROR_MASAGE:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'userid' in 'where clause'

LBL_SQL_QUERY:

SELECT * FROM u_yf_watchdog_module WHERE userid = ?

LBL_SQL_PARAMS:

5

LBL_BACKTRACE:

0 PearDatabase->checkError('SQLSTATE[42S22]: Column not found: 1054 Unknown column 'userid' in 'where clause'','','SELECT * FROM u_yf_watchdog_module WHERE userid = ?',[5]) in include/database/PearDatabase.php(336):

1 PearDatabase->pquery('SELECT * FROM u_yf_watchdog_module WHERE userid = ?',[5]) in modules/Vtiger/models/Watchdog.php(108):

2 Vtiger_Watchdog_Model->getWatchingModules('','') in modules/Vtiger/models/Watchdog.php(64):

3 Vtiger_Watchdog_Model->isWatchingModule() in modules/Vtiger/models/ListView.php(41):

4 Vtiger_ListView_Model->getHederLinks([Contacts,List]) in modules/Vtiger/views/List.php(78):

5 Vtiger_List_View->preProcess() in include/main/WebUI.php(84):

6 Vtiger_WebUI->triggerPreProcess() in include/main/WebUI.php(214):

7 Vtiger_WebUI->process() in index.php(26):

I try reading through them, but I'm not sure what to do. How can I repair this. As soon as I repair this issue, I probably restart with a fresh database and version.

Can anyone provide insight?

Thank you.

Luck saved me again. Was about to give up and hope for answer to arrive here sometime in the future from other user.

I look carefully and saw this "u_yf_watchdog_module". I remember seeing u_yf database in myPHPadmin. So I tried searching for it and found 1 results.

Great. This look like this is my ticket out of here. To be careful of future error, this is what I did.

I made an second subdomain called Test. I'll probably be using this for future testing before using the main/production server.

This "test.websitename.com", I install version 3.4 with, create a new database for it. After install, I do not touch anything. As it will be a "pure" version. Untainted by my impatiences.

I opened myPHPadmin, open the new database, search for "u_yf_watchdog_module", and I see a "userid" column in this database but not in my main/production database.

I made a column call userid using the "pure" database as references. There doesn't seem to be any data for this, only column name from the look of it. Crossed my finger. Refresh. And the "Contacts" page loaded.

Success. Now time to wait for v4.0 or v3.5 and I'll made the move.

Wasn't fun, but a good learning experience. I open a few other module and it view fine. Add record seem to work. Delete also. Best of luck to those with the same issue. Post it, maybe we can figure it out together or something.

I want to try the latest developer version. In particular I'm using this one: https://github.com/YetiForceCompany/YetiForceCRM/commit/68e63334ba6330214b59375b37d9b06704c2ae72

I'm getting a 500 Error with this version. Looking at Error Log, I'm getting these:
.htaccess: IdleTimeout not allowed here

<IfModule mod_fcgid.c>
    IdleTimeout 600
 ProcessLifeTime 600
IPCConnectTimeout 600
    ConnectTimeout 600
    BusyTimeout 600
</IfModule>

Changing these to a comment with # in doesn't help.
Removing the whole thing doesn't work.
Adding: Fcgid in front like so, doesn't work.

<IfModule mod_fcgid.c>
    FcgidIdleTimeout 600
    FcgidProcessLifeTime 600
    FcgidIPCConnectTimeout 600
    FcgidConnectTimeout 600
    FcgidBusyTimeout 600
</IfModule>

Anyone know why? Look like it only related to a module name: mod_fcgid

I tried reading this https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgididletimeout among other site but no luck yet.

It would seem like the culprit is this section.
<IfModule mod_fcgid.c>

I re-tried from a fresh new install 3.4. Then using the Update Patch to
3.4.0_to_3.5.0_4Beta.zip Added change to update package from 3.4.0 to 3.4.1427
and this htacess / mod_fcgid.c is causing an issue with my current hosting (hostgator).

Researching this keyword doesn't seem to help, no one seem to post anything (at least I couldn't find any) regarding this error.

Either hostgator blocked my type of account (shared hosting and not delicate server or VPS, etc) from using this "module" or it could be because my Apache version is too old:

Apache: v2.2.31 rather than the 2.4 recommended.

So my option are:
1) Hope I did something wrong there it is usable once I figure it out.
2) v3.5 or higher will be it compatibility once it goes stable.
3) I'm stuck with v3.4 or go to another CRM/system.
4) Move to another Hosting company that does more freedom/feature.

Looking forward to Option 2 or maybe Option 1.

Delete condition <IfModule mod_fcgid.c>

@mariuszkrzaczkowski Thank you. I've already tried that, get a blank page afterward instead of 500 internal error.
Please see post: https://github.com/YetiForceCompany/YetiForceCRM/issues/3910#issuecomment-275906015

It seem like newer Yetiforce version is dependent on this module.

Here some test trial logs. Where
s2.com is site name (censored)
username (censored)
211.ip.address (censored)

[Mon Jan 30 06:20:02 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: FcgidIdleTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:19:40 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IdleTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:10:19 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: </IfModule> without matching <IfModule> section, referer: http://s2.com/
[Mon Jan 30 06:05:02 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: BusyTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:04:47 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IPCCommTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:04:41 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IPCCommTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:04:14 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IPCConnectTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:03:51 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IdleTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:03:51 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IdleTimeout not allowed here, referer: http://s2.com/
[Mon Jan 30 06:03:50 2017] [alert] [client 211.ip.address] /home4/[username]/public_html/s2.com/.htaccess: IdleTimeout not allowed here, referer: http://s2.com/

Looking through the logs, it basically I used, "#" to comments out each part. Eventually even the

<IfModule mod_fcgid.c>

I wanted you to delete the entire condition, namely:

<IfModule fcgid_module.c>
    FcgidIOTimeout 600
    FcgidConnectTimeout 600
    FcgidBusyTimeout 600
    FcgidIdleTimeout 600
</IfModule>
<IfModule mod_fcgid.c>
    IdleTimeout 600
    ProcessLifeTime 600
    IPCConnectTimeout 600
    IPCCommTimeout 600
    BusyTimeout 600
</IfModule>

Change display_errors -> On, you get
Warning: require(/var/www/vhosts/vendor/composer/../smarty/smarty/libs/bootstrap.php): failed to open stream: No such file or directory in /var/www/vhosts/vendor/composer/autoload_real.php on line 67

@mariuszkrzaczkowski

Hi,

I too tried again and failed. Can I ask where we would find the condition you suggest we delete? What file is it in?

@ldgbc
There’s just one error in here, the update to the new version was stopped by the server, in this case the problem should’ve been analyzed and solved, and then you should’ve performed the update on a copy. All you described is a very detailed manual on how not to update the system. The first and most important rule when it comes to updating the system is to always perform it in a test environment first, and create a backup copy before performing the update.
Unfortunately you may stumble upon a number of errors in your system, caused by an incorrect update procedure. This might also cause future updates to be incorrect. If at some point you want, and have the budget for that, our programmers can verify and fix your problems, but you’ll need a support package for that.

@PercyP You can use File Manager in

CPanel > www or public_html > websitename.com > .htaaccess (right click that > edit > comments or delete out the section instructed by @mariuszkrzaczkowski.

I tried on the Developer version and there was no more Error Logs. But the website doesn't load at all.

@paula-w Thank you for your input Paula. But that is exactly right, I pretty much

very detailed manual on how not to update the system

I noted that in my original post, but it was a great learning experience and I avoided that now. All my test are done in environment that I can easily abandon.

As for the error, yes there seem to be only one. A module call mod_fcgid.c <IfModule mod_fcgid.c>. As for the incorrect update procedure it seem to be both related to this <IfModule mod_fcgid.c>. I tested on both the.
1) Developer Version - fresh database, commit version dated on the 25/26th Jan 2017. Maybe it will work with the 30/31 Jan 2017. I'll try again after this post.
2) and a 3.4 then update to 3.4.1427 using Update Package. On a fresh database installation.

Perhaps if I can take time to make a video/gif it might be easier to see where I went wrong.

@ldgbc

I found your detailed explanation very useful, so thank you. So much can be learnt from other people's mistakes. I did some research once I seen the errors you identified and it suggested updating some code on EasyApache (I have a VPS so can access this). It didn't work as I still get the problem.

In my case the .htaccess file has to be edited with filezilla (it is hidden in file manager on my VPS). I deleted the 2 blocks of code but it had no effect.

It is odd, that all my updates up to this point have either worked straight away, or worked after some small tweak. My environment hasn't changed, so it is puzzling why it is now possibly an apache problem.

I too will wait for a stable release and then try again :)

There some bug I want it gone in v3.4 hence the impatient attitude. I think I'll try using AMP Stack (WAMP, MAMP and LAMP) type of system (local) as a testing ground. I've play with them before and it not too complex to use. Especially since it usually include Softaculous which have plenty of other tools to play with.

Perhaps on AMP it might work (most likely will) since my hosting company (hostgator) probably just want me to upgrade my account to have more access to the server. Which I probably won't do. They don't include other packages like Softaculous, HTTPS (Let's Encrypt, etc), and doesn't look like they will be upgrading CPanel, MYSQL or PHPmyadmin any time in the near future.

Considering that, it I may look for alternative hosting company once I want to go through the pain of, "learning how to move host".

It good to see update in this issue @PercyP. It look like this issue is tagged "Ignored" so it will just be curious people like us. Only 8% more for v3.5 (or now 4.0)

I noticed that the package got changed to "3.4.0_to_3.4.1427_v1" rather than "3.4.0_to_3.5.0_4Beta"
So I decided to test it again. Unfortunately it seem like the future it set.

The error is related to this mod_fcgid.c. I tried asking my hosting company for support and they refuse to enable it. So I probably will look for alternative hosting company in the future. Any recommendation on one would be considered.

It seem like the ability to edit "httpd.conf" is only available for their VPS/Delicate account. Considering that all future update of Yetiforce (from v1427 to v17xx) seem to have this mod_fcgid.c I probably won't be able to use the update version. Unless there some workaround method or requirement change.

I just wanted to know, if any does successful install the developer version on their own server?

Look like this Issue share quite a few similarity with us.
https://github.com/YetiForceCompany/YetiForceCRM/issues/3814

I wonder if there is a shared hosting that does enable these setting if the majority or all of user of the shared hosting request it (for that particular server).

@ldgbc

can you not request access to SSH for your account from current host provider?. My hosting company allows this fore shared hosting. Maybe then you can edit that file although not entirely sure.

I doubt they will allow it since "it will affect all user on the shared hosting". They also noted that each time Apache reset, the code would be remove, which is true (based on what I been reading). However there a "custom" or "virtual" method of adding/enabling the code that so custom edit will not be affected.

Either the person I got support from don't know that or don't want to do it that. They could have recommend that I get VPS or try some other method to fix it.

Could you tell me which hosting company it is? Hostgator is not a place I would recommend.

Update: I thought you a breakthrough was in sight. I searched for SSH and found their Support Article. They do allow SSH, which is great.

Unfortunately the SSH access is the same as the CPanel's File Manager. I can't get access to higher level file (root), in particularly the file that will allow to to fix this 500 internal error issue.

@ldgbc If you comment lines 1102-1109 in file init.php in the update packade, zip again and install that, should get it work.

@ldgbc

I am in the UK so I use heartinternet (for over 7 years now). I have a reseller account, so I am not sure if my extra priviledges come with that - I would have to check. Basically, for any domain under my reseller account, I can apply for SSH access. I can view / edit all the files. You could contact them or a hosting company in your country and ask if you get this access?

@kpaulaha

I am going off to try your suggestion :) Which file is it?

@PercyP updates/init.php
comment/remove lines 1102-1109
init

Thank you for the input @kpaulaha . I'll try removing that line for the update but won't the newer version still require it? I usually get a blank page when I Comment/Remove that line in my HTAccess file.


I been reading more about this is this is something call, "fastcgi" a supposedly better method than the older standard.

I end up on a FAQ page that said it possible to enable the fastcgi using Apache Handlers. I hope it worked but it didn't for me so you can try it if you want.

CPanel > Apache Handler > Under Handler, put "fcgid-script" > Extension(s): ".php"
If it correct it will give you a "tick". My page still got error in Error Logs even after I added that.
.htaccess: IdleTimeout not allowed here


@PercyP Yeah, I think a Reseller would put on as a "admin" of that server I think. If you can access the httpd.conf it mean you have "root" access.

I'm on a shared account, so that is the 2nd lowest account available. Any lower would be "free-hosting" where they add ads on your website.

Next I'll try kpaulaha method and hope for light at the end of the tunnel.

@kpaulaha @PercyP
Look like progress was made at least. I followed your method of removing those lines. I didn't get a Blank/White page (doesn't load) this time.

It instead give me a 404 error page because it trying to access, "/install" path. So I copied a v3.40 install folder in there.

Refresh and it worked. I can see the version been changed, The homepage appear. Look like it worked. But I learnt my lesson. I test by going to Contact > Add Record.

But before Add Record I got this error,

`Error!!!

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'vnproper_paul.vtiger_firstname' doesn't exist Failed to prepare SQL: SELECT firstnameid, firstname FROM vtiger_firstname ORDER BY `sortorderid``

But Account seem to work. I can Add, View, Delete,

If I rename the "/Install" or remove it. I will get an 404 error again. A workaround is just to add /index.php at the end of your website. For example, www.websitename.com/index.php

This would mean that my installation was incomplete so it still not fully functional. I'll look into fixing the Contact table and hopefully that way I can at least use version 1427 and possible the 1800+ version currently now.

This is great progress to be made.
I went into Admin > Log > update
The status said, "Yes" so it trigger a successful installation I suppose.

Thank you.

Update:
After I post this message, I decide to do more testing. I thought, maybe I can rebuild the table by tricking Yeti into making it. I went to
Admin > Standard Modules > Clicked First Name > Mandatory > Save
Open Contact and it didn't get the error anymore. I think this is it. The tunnel we been waiting for.

Base on my test it is usable however my Updates Logs (contact/account, etc update logs) does not seem to work. Any change, delete or alteration doesn't get log.

In term of feature or UI design change there isn't anything noticeable. I was hoping it easier to use (vTiger 7 interface provide some of that easiness.) Especially in terms of Detail view with it, numbers next to icon so you know about it. And the linkage of thing such as Asset and Ticket to Contact and not just Account. But I suppose those feature will just have to wait till one of Yetiforce client requested it.

I don't know if this is relevant at all, but I looked in the Logs-Updates of my crm and noticed that the last update I did to version 3.4 (which also required installing the hotfix) shows as Updated from version 3.4 to version 3.4.21

The current update is for version 3.4 to 3.4.1427 which is a lower version number than what appears to be installed after running the original hotfix.

I took a look inside the yetiforce/config/version.php (which we used to have to change prior to running an update, and mine looks different, and now only contains the following information:

<?php return [ 'appVersion' => '3.4.0', 'patchVersion' => '2016.10.10', 'lib_mPDF' => '0.0.0', 'lib_roundcube' => '0.0.2', 'lib_PHPExcel' => '0.0.0', 'lib_AJAXChat' => '0.0.0', ];

Could this be one of the reasons I cannot get the latest update to install?

That good investigation. I haven't delve into reading the code yet (I can only read basic and obvious one either way) as this is more of a hobby for me at the moment.

However it certainly something to take note of when I try again. The issue here is that, this "bug" occur even if I don't use the Hotfix Patch .21 and trying to update on a fresh database and a installation of 3.4 without anything change or edit.

I tried YetiForceCRM-developer-3.4.1762 today. Thought I go to some file editing and see if I can get it to work. It look like the .htaaccess module have been updated 2 days ago.

And it indeed fixed up one of the Errors. I don't get the "not allowed here". So that was a good sign. Still got a blank page though. Looked at the error and it is missing some, "Standalone Logo 250px". I made copy one of Yeti force logo and rename it as it required.

Refreshed the page but still Blank page.
Refresh Error Logs, no change in logs.
Went and enable Loggings (the documentation seem to be outdated or logging doesn't seem to work). No logs files so I gave up.

Good news is that the .HTACCESS error have been fixed and that is one good sign for me.

Please check Apache, PHP, and CRM logs.

log
log

Weekend soon. That mean Yetiforce won't be updated till they come back on Monday.

Anyway, just a small update. I thought, maybe that I didn't have my PHP setting correct so that why it not working. I went to
https://yetiforce.com/en/administrator-documentation/instalation/103-web-server-requirements.html
And check all the recommended setting. I enable, change value, etc. Tested v3.4.1762 again.
I got a 500 page error. No error logs. Well that better than blank/white page I suppose.

I went to my stable v3.4 version and it got 500 internal error too. Well that not good. Went back to the setting and tried to remember which value I changed. As luck have it, it was this single value that caused the error.

register_globals: on

It was listed twice for some reason (probably user/documented error). So if you have a 500 Internal Error, try disabling that.

Aside from that, my previous memory_limit: 256M, I changed that to 512 now. hopefully that mean it more responsive.


It seem like the white/blank page is still a 500 Internal Page error. I used F12 (Developer Toolbar) and that the code it give.

@ldgbc - we just updated the requirements, thanks a lot for letting us know that it was listed twice 😄.

Update 3.4.1427 to 3.4.1780v1 works excellent here.

@kpaulaha

Hi,

did you first update to 3.4.1427 or did you just use the latest version?

I managed to do the first one, but the 3.4.1427 to 3.4.1780v1 fails every time, so was wondering what you might have done differently. This is the new thread I posted regarding my issue:

https://github.com/YetiForceCompany/YetiForceCRM/issues/3996

@PercyP Updated earlier 3.4 -> 3.4.1427, now to 3.4.1780v1. Just started it, went for coffee and it was ready without any errors. You can check it out http://yf.tigersoft.fi

@kpaulaha

thanks. The only difference I can see between my instance and yours is that the Logs-Updates are showing different values. Did you use these files:

https://github.com/YetiForceCompany/UpdatePackages/tree/developer/YetiForce%20CRM%203.x.x/3.4.0_to_4.0.0/zip

Also, did you change the config/version.php at all? I know we used to have to do this, but didn't think it was necessary any more.
updatelog

I notice you have an extra update after the hotfix - maybe I need to add that first? Where did you download that update?

@PercyP Used the very same, except the first version of 3.4.1427 with a little modification of .htaccess.
I don't think there is any extra update after hotfix, it's the same you have 3.4.1427, it's just marked 03/04/1427 for some reason when using comma as separator. And as you can see on that server configuration it's not quite as demand.

@kpaulaha

can I ask what yo modified in htaccess? Maybe this is my issue

@PercyP I removed the fastcgi (mod_fcgid.c) as that server then did not accept that, but I guess you have done the same or it works for you. I think it is removed from the v2 of the 3.4.1427 update.

@kpaulaha

this is so puzzling.

To see if I could establish the cause, I tried changing the .htaccess in the root of yetiforcecrm folder to htaccess.txt - I still got thrown out of the install process (back to my website home page). So I renamed it back. Then I did the same for the .htaccess in the root of my website and it finally showed an error:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

This time in the URL it showed the following (whereas before it just went to my home page):

/yetiforcecrm/cache/updates/init2.php?from_version=3.4.1427&to_version=3.4.1780

I notice there are 2 init.php files in the update folder (in previos version there was only one).

I am starting to think it must be a problem with one of my server settings

@PercyP Yup, check your server, just tried to update to 3.4.1780 on 2 other servers, ubuntu and other even windows, both ok without problems.

@kpaulaha

I am at a loss. It doesn't make sense that the first update worked perfectly and then the second fails in the same environment. When I compared both mine and your server configurations, as you say, your isn't meeting all their requirements. Mine does - except those optional ones plus the session.cookieHTML which I cannot find on my server so cannot enable it.

Maybe one of the developers can shed some light on it

@PercyP Nothing written to the server logs? And nothing with display_errors=on?

@kpaulaha I tried your server on http://yf.tigersoft.fi/
to download the Roundcube module but it doesn't work on yours either. So I guess it a bug. Are you able to find out why/create issue for that?

http://yf.tigersoft.fi/index.php?module=ModuleManager&parent=Settings&view=List

@ldgbc
Log says:
[13-Feb-2017 15:40:39 Europe/Helsinki] PHP Warning: file_get_contents(https://github.com/YetiForceCompany/lib_mPDF/archive/0.0.2.zip): failed to open stream: HTTP request failed! HTTP/1.0 404 Not Found

Have asked about it earlier #3884

Download the libraries will not work if you will not be officially published a new version of the system.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michelmarquesrj picture michelmarquesrj  Â·  3Comments

johntonji picture johntonji  Â·  3Comments

ldgbc picture ldgbc  Â·  3Comments

RedMoon27 picture RedMoon27  Â·  3Comments

liberox picture liberox  Â·  3Comments