SuiteCRM 8.0.4 on Ubuntu 20.04, apache2, mariadb, php-8.0 fails with validation errors

SuiteCRM Forum - English Language Installation & Upgrade Help
,
1

G’day,

I’ve tried this multiple times, trying to confirm I’m doing things right, but I get the same error - whether on Ubuntu 20.04 on my Proxmox server or on an Oracle ARM cloud VM instance.

In this particular instance, I’m running the following:
Ubuntu 20.04 with all the latest apt updates (on Proxmox)
apache2 - Apache 2.4.41-4ubuntu3.10
php 8.0.17
SuiteCRM 8.0.4

Install OS, install as per the docs at https://docs.suitecrm.com/8.x/admin/installation-guide/downloading-installing/, create a mariadb database for SuiteCRM, extract the SuiteCRM zip file, create a suitecrm.conf file, go to the http://suitecrm.localdomain (and yes, there’s a local DNS entry for this) and see the expected install screen.

Welcome to SuiteCRM
INSTALL
Ignore System Check Warnings:
PROCEED
LICENSE
CONFIGURATION
SUITECRM LICENSE:
GNU AFFERO GENERAL PUBLIC LICENSE
Version 3, 19 November 2007…

Then when clicking on Accept and Proceed, receive the following error message:

There are validation errors, unable to perform action.

And nothing. No go.

I have confirmed that rewrites are happening - if I follow the “Debugging the problem” steps in https://community.suitecrm.com/t/suitecrm-8-beta-install-questions/79383/3 I get the expected 404 error. I have also checked the “about” redirection as per How to Rewrite URLs with mod_rewrite for Apache on Ubuntu 20.04 | DigitalOcean and all is good.

So, I can then perform a manual install using console suitecrm:app:install which works, and then rerun the permissions steps. But when it installs I get the following message:

SuiteCRM Silent Install

Running: check-install-lock
step: check-install-lock | status: done
Installer not locked. Proceeding with install
Running: check-db-connection
step: check-db-connection | status: done
DB credentials ok
Running: install-system-checks
step: install-system-checks | status: done
Running: create-config
step: create-config | status: done
Created silent install config: config_si.php
Running: create-env
step: create-env | status: done
Created .env.local
Running: run-legacy-install
step: run-legacy-install | status: done
Legacy install successful

Any ideas why I’m getting a legacy install (and for that matter, what a legacy install of SuiteCRM 8.0 actually means)?

2

Hi @HiltonT,

There are 2 tabs you’ll need to click throught before hitting continue. 1st being the license, 2nd being config options. Try clicking the other tab at the top of the page and fill out the values there.

As for the silent install, “Legacy” install is part of the install which configures the Suite7 subsystem. That message appears complete and I would expect your system to be installed correctly.

3

AHA!!! :smiling_face:

Well, that wasn’t particularly clear even after multiple installs.

Can I make a suggestion that, for blind cnutz like me, you make a slight change to 2.1.2 in the SuiteCRM 8 Install Docs so it reads something like “The next step is to click on the “CONFIGURATION” tab up top and add the base system configuration in order for your system to work.”

Now, as to the “Legacy” part, is this normal? Am I missing something? Does Suite 7 need to be installed when I’m installing Suite 8? With this “Legacy” stuff, this means that a lot of the paths referred to in the docs for configuration files for SuiteCRM 8 are incorrect as they aren’t under the SuiteCRM root, nor even under “public”, but are instead under “public/legacy”.

If this is the way it always installs, that’s fine, but I’m still not clear on what this “Legacy” stuff is. If this is the normal install, can we please update the SuiteCRM 8 docs to reflect these correct paths?

4

Hey @HiltonT,

Glad to hear the install worked for you, for sure I’ll look at updating the SuiteCRM Docs site and suggest to the team we make the visibility of the 2 tabs more clear.

As for legacy;
SuiteCRM 8 is not yet a fully standalone product and relies on some parts of the SuiteCRM 7 functionality, this is also to allow for decent quality backwards compatibility when migration from SuiteCRM 7 to 8 becomes an option for the wider community.

Inside of suiteroot/public/ you will find a legacy/ folder which contains a full up to date SuiteCRM 7.12.x installation, which during the SuiteCRM 8 install would have been configured and set up with the same credential you provided. SuiteCRM 8 will make calls, requests and sometimes directly display SuiteCRM 7 views to the front end, therefore allowing customisations and the likes which previously existed to be viewed and used like normal.

The only changes you may need to make would be to the .htaccess found in the legacy/ folder, where a bug currently does not update it to point correctly causing “undefined” labels.
In this file you should find one or more rewrites pointing to suiteroot/legacy/ which should be changed to the full path suiteroot/public/legacy/

Other than this temp fix for a known issue, there is no requirement to configure anything else on the SuiteCRM 7 side. You are effectively using SuiteCRM 8 which sometimes often without knowing makes use of SuiteCRM 7 to achieve what you ask it to do.

Hopefully, that all makes sense (Its early UK rn xD) and clears up any questions. If not feel free to toss them below :+1:

1 Like
5

Yeah, that explains a lot. :slight_smile:
The only reference at all in suiteroot/public/legacy/.htaccess is on line 22:

RewriteBase /legacy/

Should that be changed to /public/legacy/?

Also, as an aside, I have another post up asking if I should mod the core modules, or just recreate n entire set from scratch as I am trying to develop a bit of a solution for some not-for-profit orgs with SuiteCRM. So I want to add some modules and some relationships to the core modules, and add some fields and change it from a business-focussed setup to a more person-focussed setup. An example would be to assign Cases to a Contact, not an Account.

Do you happen to have any thoughts on this?

I really think using and modifying the core modules is the way to go, but I’m having difficulties working out how to deploy these chan ges to a new instance as compared to Module Builder and deploying through that…

6

Ye, updating from /legacy/ to /public/legacy/ should work around the issues in that bug.

As for the second question pedro has tossed some decent info there but tldr is yes, if your creating a bespoke system i’d always suggest editing core modules while adding new modules where needed. This should be done via the customs/extentions/<modulename> folder for backend changes like fields, labels, dropdown options, etc (tho can be done via studio (found in top right dropdown > administation > studio) if you’re less code savey like me). In SuiteCRM 8, front end changes like buttons, menus, popups or panels are done via the new extention system of which more details can be found here.

As for transfering between systems, you need the customs folder for backend changes, the extentions for front end suitecrm8 changes and the database cstm table which should allow for a duplicated install. Github would be your friend in this sitation.

1 Like
7

Aahhh, I was sidetracked and didn’t see Pedro’s response.

Thanks for the additional info. I’ll have a read of Pedro’s reply in a sec.