CMS Made Simple Forums

I am the new web manager for the website www.agmc.info and, in trying to look up a user, I have clicked on something that has completely broken the interface. I've attached a screenshot of the only things visible now. Help.

To help us diagnose the issue, make sure to include the following:
-Version of CMSMS
-The module & version you're using for frontend user management (likely either FrontEndUsers or MAMS)
-PHP version
If you go to Site Admin > System Information, there's a button near the top called "View Text Report". If you paste this into your forum reply it will answer all of the above and more.

For that type of error there should also be an entry in your php error log and/or admin log. Check with your web developer (person/company who built your site), server admin, or hosting company if you don't know how to find this.

Here is the info:

----------------------------------------------

Cms Version: 2.2.19

Installed Modules:

AdminSearch: 1.0.6
CGCalendar: 2.5.1
CGExtensions: 1.61
CGSimpleSmarty: 2.2.1
CMSContentManager: 1.1.12
CmsJobManager: 0.1.3
DesignManager: 1.1.10
FileManager: 1.6.16
FilePicker: 1.0.7
FrontEndUsers: 2.11
MenuManager: 1.50.3
MicroTiny: 2.2.5
ModuleManager: 2.1.9
Navigator: 1.0.10
News: 2.51.12
Search: 1.53
SelfRegistration: 1.14.3
Uploads: 1.25.8


Config Information:

php_memory_limit:
max_upload_size: 64000000
url_rewriting: none
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: America/Denver
permissive_smarty: false


Php Information:

phpversion: 8.2.21
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 22517
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: -1
max_execution_time: 50000
register_globals: Off (False)
output_buffering: 0
disable_functions:
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 64M
upload_max_filesize: 64M
session_save_path: /tmp/.priv (1733)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: Off (False)
curl: On


Performance Information:

allow_browser_cache: On (True)
browser_cache_expiry: 60
php_opcache: Off (False)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
auto_clear_cache_age: On (True)

Server Information:

Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 4.4.400-icpu-099 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.7.42
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable


Permission Information:

tmp: /homepages/9/d508831033/htdocs/tmp (0705)
tmp_cache: /homepages/9/d508831033/htdocs/tmp/cache (0705)
templates_c: /homepages/9/d508831033/htdocs/tmp/templates_c (0705)
modules: /homepages/9/d508831033/htdocs/modules (0705)
uploads: /homepages/9/d508831033/htdocs/uploads (0705)
File Creation Mask (umask): /homepages/9/d508831033/htdocs/tmp/cache (0705)
config_file: 0444

----------------------------------------------


I'm trying to locate PHP error logs. I can't be specific for what I did when the error occurred, but I had the Frontend User Management page open and couldn't get individual user info to display, so I changed a pulldown that was set to "All," I believe, to "Active" or "Live" or something similar. The pulldown only had three options.

I think the problem is going to be that FrontEndUsers likely only works with PHP 7.x. FEU hasn't been updated since 2019 when its author ceased development, and PHP 8.2 was released in 2022. A temporary workaround may be to try rolling back to an older PHP version. A more long-term solution would be migrating to MAMS.

I've only been managing the website for a short time, but as I understand it, a PHP upgrade caused issues and for the past year or so, we've been operating with PHP 7.4, with extended support from our hosting company for the older version. It looks like we're now current (PHP 8.2.21) and I don't know if I could have somehow caused that to occur or if the hosting company made the change. I guess I need to contact them to see if they can do a rollback.

The PHP version is definitely the issue, and it's likely the hosting company made that change. If they don't offer an option to roll it back, you'll likely need to have a web developer copy the site to a server with PHP 7.4, do the migration to MAMS, then transfer it back to your server. If you don't have a developer available to do this, see the link in my signature for our hire-a-dev program.

They did a rollback, but it hasn't corrected this specific problem.

Cms Version: 2.2.19

Installed Modules:

AdminSearch: 1.0.6
CGCalendar: 2.5.1
CGExtensions: 1.61
CGSimpleSmarty: 2.2.1
CMSContentManager: 1.1.12
CmsJobManager: 0.1.3
DesignManager: 1.1.10
FileManager: 1.6.16
FilePicker: 1.0.7
FrontEndUsers: 2.11
MenuManager: 1.50.3
MicroTiny: 2.2.5
ModuleManager: 2.1.9
Navigator: 1.0.10
News: 2.51.12
Search: 1.53
SelfRegistration: 1.14.3
Uploads: 1.25.8


Config Information:

php_memory_limit:
max_upload_size: 64000000
url_rewriting: none
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: America/Denver
permissive_smarty: false


Php Information:

phpversion: 7.4.33
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 22517
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: -1
max_execution_time: 50000
register_globals: Off (False)
output_buffering: 0
disable_functions:
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 64M
upload_max_filesize: 64M
session_save_path: /tmp/.priv (1733)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: On (True)
curl: On


Performance Information:

allow_browser_cache: On (True)
browser_cache_expiry: 60
php_opcache: Off (False)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
auto_clear_cache_age: On (True)

Server Information:

Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 4.4.400-icpu-099 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.7.42
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable


Permission Information:

tmp: /homepages/9/d508831033/htdocs/tmp (0705)
tmp_cache: /homepages/9/d508831033/htdocs/tmp/cache (0705)
templates_c: /homepages/9/d508831033/htdocs/tmp/templates_c (0705)
modules: /homepages/9/d508831033/htdocs/modules (0705)
uploads: /homepages/9/d508831033/htdocs/uploads (0705)
File Creation Mask (umask): /homepages/9/d508831033/htdocs/tmp/cache (0705)
config_file: 0444

----------------------------------------------

I just checked some notes I had from years ago, and the version of FEU you're using (2.11) looks like it may need PHP 5.6, or possibly 7.0 or 7.1 but nothing higher. If that's not an option, you could try upgrading to a newer FEU (do *not* go to the 3.0 branch, but you could try the latest in the 2.x branch, which I think is 2.14.3.4).

Make sure you have a full backup before trying any module upgrades, there's no method for undoing it.

It was working fine last week under 7.4, so I'm not sure what I'm going to do. We're a small non-profit, so I'll have to look for other solutions.