Recent Posts
31
CentOS-WebPanel Bugs / Re: CWP Cronjob Killing Server
« Last post by venty on August 16, 2026, 07:51:56 PM »Only errors I really see in over 1/2 of the above is that PHP Intl is missing.
MariaDB 10.5.x is way past EOL also.
I'm guessing the OS is CentOS 7?
Hi,
PHP Intl is missing +1 --- appeared as a warning after one of the AL 9 updates?!?
message about the daily backup:
"/etc/cron.daily/cwp:
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0"
Thanks in advance!
BR
Venty
32
PHP / PHP-FPM Won't install zlib says missing dependency zlib-dir
« Last post by DA_MAN on August 16, 2026, 06:51:18 PM »When trying to compile PHP 8.4.x PHP FPM custom selector throws error saying "zlib-dir" is a dependency of zlib which in 8.4.x zlib-dir or zlib-develop is baked into PHP version 8.4.x to my knowledge. This missing dependency doesn't allow PHP-FPM to be compiled with custom settings because of the missing zlib-dir dependency.
From what I can tell from research is that zlib-dir is no longer needed in PHP8.4.x and should not be throwing the error. Compiling without zlib does not allow gzip page compression, so this is a deal breaker.
From what I can tell from research is that zlib-dir is no longer needed in PHP8.4.x and should not be throwing the error. Compiling without zlib does not allow gzip page compression, so this is a deal breaker.
33
CentOS-WebPanel Bugs / Re: CWP Cronjob Killing Server
« Last post by wingusupport on August 16, 2026, 04:59:49 PM »Hi @Starburst,
This is a fairly new install using AlmaLinux 9. The PHP error seems benign. I see it on my other CWP servers running Rocky Linux 8 also. I am wondering if it has to do with:
"cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory"? I don't think it does, just the only other error that just pops out.
I installed the new server using the CWP installation script about 1.5 months ago.
Thanks.
This is a fairly new install using AlmaLinux 9. The PHP error seems benign. I see it on my other CWP servers running Rocky Linux 8 also. I am wondering if it has to do with:
"cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory"? I don't think it does, just the only other error that just pops out.
I installed the new server using the CWP installation script about 1.5 months ago.
Thanks.
34
CentOS-WebPanel Bugs / Re: CWP Cronjob Killing Server
« Last post by Starburst on August 16, 2026, 04:40:07 PM »Only errors I really see in over 1/2 of the above is that PHP Intl is missing.
MariaDB 10.5.x is way past EOL also.
I'm guessing the OS is CentOS 7?
MariaDB 10.5.x is way past EOL also.
I'm guessing the OS is CentOS 7?
35
CentOS-WebPanel Bugs / CWP Cronjob Killing Server
« Last post by wingusupport on August 16, 2026, 04:36:15 PM »I have been fighting with this problem for days. Seems to have started after a few rounds of software and security updates a few days ago. I have finally narrowed the issue down but have not come up with a permanent fix. I think only CWP can provide the fix.
Also, I fully admit, this could be something I caused. Just yet to determine where or what.
CWPpro version: 1.8
Operating System: AlmaLinux 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
FTP version: 1.0.52
SSH Port: 4000
MySql Port: 3306
Web Servers: nginx-apache
Problem: After the CWP cronjob runs, the permissions on Mariadb are modified rendering the server unusable. No websites, no webmail, no service at all.
Testing: To recreate problem that forced me to manually fix the dead CWP server (after determining the what was triggering the issue), run # bash /etc/cron.daily/cwp.
Output: However, the PHP warning seems benign.
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
====================================================
============= CentOS Web Panel Cron ================
====================================================
###########################
Firewall Flush Daily Blocks
###########################
######################
Update Server Packages
######################
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
grep: /usr/local/cwpsrv/logs/error_log: binary file matches
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Redirecting to /bin/systemctl restart cwpsrv.service
Redirecting to /bin/systemctl restart httpd.service
Redirecting to /bin/systemctl reload httpd.service
Redirecting to /bin/systemctl reload nginx.service
Redirecting to /bin/systemctl reload httpd.service
cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Date which backup script is using: 2026-08-16 12:15:07
# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details.
Temporary Fix: I manually execute the following every morning now to resuscitate the CWP Server. Clients are not happy with this arrangement.[/]
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
Permanent Fix: Not discovered yet. Hoping for a CWP team based solution as the scripts are not viewable nor modifiable. I'm okay with that. Just hoping for a permanent solution fix.
In addition: I have three CWP server that the NEW Backup (beta) restore feature does not show the Restore Points for the user account. All of this started about the same time.
Automated Temporary Fix:
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
Step One:
cat << 'EOF' > /etc/cron.daily/dw-fix-mariadb
#!/bin/bash
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
EOF
Step Two:
chmod +x /etc/cron.daily/dw-fix-mariadb
Step Three:
bash /etc/cron.daily/dw-fix-mariadb
Step Four:
Keep checking server each morning to be sure it's running properly.
Also, I fully admit, this could be something I caused. Just yet to determine where or what.
CWPpro version: 1.8
Operating System: AlmaLinux 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
FTP version: 1.0.52
SSH Port: 4000
MySql Port: 3306
Web Servers: nginx-apache
Problem: After the CWP cronjob runs, the permissions on Mariadb are modified rendering the server unusable. No websites, no webmail, no service at all.
Testing: To recreate problem that forced me to manually fix the dead CWP server (after determining the what was triggering the issue), run # bash /etc/cron.daily/cwp.
Output: However, the PHP warning seems benign.
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
====================================================
============= CentOS Web Panel Cron ================
====================================================
###########################
Firewall Flush Daily Blocks
###########################
######################
Update Server Packages
######################
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
grep: /usr/local/cwpsrv/logs/error_log: binary file matches
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Redirecting to /bin/systemctl restart cwpsrv.service
Redirecting to /bin/systemctl restart httpd.service
Redirecting to /bin/systemctl reload httpd.service
Redirecting to /bin/systemctl reload nginx.service
Redirecting to /bin/systemctl reload httpd.service
cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Date which backup script is using: 2026-08-16 12:15:07
# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details.
Temporary Fix: I manually execute the following every morning now to resuscitate the CWP Server. Clients are not happy with this arrangement.[/]
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
Permanent Fix: Not discovered yet. Hoping for a CWP team based solution as the scripts are not viewable nor modifiable. I'm okay with that. Just hoping for a permanent solution fix.
In addition: I have three CWP server that the NEW Backup (beta) restore feature does not show the Restore Points for the user account. All of this started about the same time.
Automated Temporary Fix:
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
Step One:
cat << 'EOF' > /etc/cron.daily/dw-fix-mariadb
#!/bin/bash
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
EOF
Step Two:
chmod +x /etc/cron.daily/dw-fix-mariadb
Step Three:
bash /etc/cron.daily/dw-fix-mariadb
Step Four:
Keep checking server each morning to be sure it's running properly.
36
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by xelavalle on August 15, 2026, 08:49:19 PM »As I mentioned in my previous response, the cause of the hack has been located; it's in geodim's answer.
It was infected with a backdoor Python script running as a fake ntpd process. The redirection is handled by a fake Apache module, mod_auth_form.so, which links to the libcurl library.
I'm almost certain that these fake files were uploaded to my server during the last CWP File Manager breach.
The link geodim provided (https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them) contains the steps to verify whether the files are real or fake, and to proceed with terminating the hacker's service and deleting those files.
In my case, the strings check didn't find any suspicious strings within mod_auth_form.so, but it failed the RPM integrity check, resulting in a checksum indicating a fake mod_auth_form.so file.
Similarly, the fake /usr/bin/ntpd file was enormous, many megabytes in size, while the originals are small.
By killing the service, deleting those files, and restarting Apache, the selective redirection disappeared.
It was infected with a backdoor Python script running as a fake ntpd process. The redirection is handled by a fake Apache module, mod_auth_form.so, which links to the libcurl library.
I'm almost certain that these fake files were uploaded to my server during the last CWP File Manager breach.
The link geodim provided (https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them) contains the steps to verify whether the files are real or fake, and to proceed with terminating the hacker's service and deleting those files.
In my case, the strings check didn't find any suspicious strings within mod_auth_form.so, but it failed the RPM integrity check, resulting in a checksum indicating a fake mod_auth_form.so file.
Similarly, the fake /usr/bin/ntpd file was enormous, many megabytes in size, while the originals are small.
By killing the service, deleting those files, and restarting Apache, the selective redirection disappeared.
37
Updates / Re: CWP 1.8 – Can we have a clear Production Readiness / Fixed Issues list?
« Last post by Xweb on August 15, 2026, 12:29:25 PM »Coming back to the actual purpose of this thread
Thanks for the formatting suggestion. I will use BBCode for the forum posts.
However, I would like to bring the discussion back to the actual purpose of this thread, because the technical questions raised in the original post are still unanswered.
The purpose was not to produce a perfect-looking post, nor to complain about individual bugs.
The purpose was to try to create, together with the CWP team and the community, a single place where we can establish the current production status of CWP 1.x.
At the moment, we have individual forum threads reporting individual problems, but it is often difficult to determine:
For a system administrator running production servers, this information is extremely important.
The question is very simple:
Can I safely update my production CWP server, and if I do, what should I specifically monitor afterwards?
This is why I believe a simple, maintained status list would be much more useful than scattered individual reports.
I would especially like to keep the focus on Backup / Restore / Reporting.
The New Backup system has been in beta/development for a long time, and I think we need to distinguish three different things:
1. Backup
Does the backup job actually complete correctly, both locally and remotely?
2. Restore
Can we reliably restore an account from that backup when we actually need it?
This is probably the most important question.
A backup that reports "completed successfully" is only useful if the corresponding restore has also been tested and is reliable.
Can CWP clarify which restore scenarios are currently tested and considered production-ready?
3. Email reporting
This is a separate issue that I have personally reported.
Even when a backup job runs, the administrator needs reliable reporting:
If the backup runs but the notification is missing or incomplete, the administrator does not have reliable visibility of the backup status.
This is why I don't think "use an external backup solution" answers the question.
Administrators can certainly use external backup systems, and many of us do.
But CWP also provides a Backup/Restore system, and it is reasonable to ask what its current production status actually is.
The same applies to the update process.
I understand that emergency security releases can sometimes require accelerated development and reduced testing.
However, after such releases, it becomes even more important to clearly communicate:
The CWP changelog currently does not provide enough detail for an administrator to reconstruct this information reliably.
So I would like to ask the CWP team directly:
Could you please provide an updated status for the issues raised in this thread?
Even a simple table would be enough:
It does not need to be perfect.
What matters is having a clear reference that allows administrators to understand:
what is fixed, what is not fixed, what is still beta, and what requires attention before updating a production server.
That was the reason for opening this thread in the first place.
I would really appreciate a technical response from the CWP team so that we can turn this into something useful for the whole community.
Thanks for the formatting suggestion. I will use BBCode for the forum posts.
However, I would like to bring the discussion back to the actual purpose of this thread, because the technical questions raised in the original post are still unanswered.
The purpose was not to produce a perfect-looking post, nor to complain about individual bugs.
The purpose was to try to create, together with the CWP team and the community, a single place where we can establish the current production status of CWP 1.x.
At the moment, we have individual forum threads reporting individual problems, but it is often difficult to determine:
- whether the problem is a known CWP regression;
- whether it was introduced by a specific update;
- whether it has already been fixed;
- which CWP version contains the fix;
- whether the fix has actually been tested;
- or whether the problem is still considered known/open.
For a system administrator running production servers, this information is extremely important.
The question is very simple:
Can I safely update my production CWP server, and if I do, what should I specifically monitor afterwards?
This is why I believe a simple, maintained status list would be much more useful than scattered individual reports.
I would especially like to keep the focus on Backup / Restore / Reporting.
The New Backup system has been in beta/development for a long time, and I think we need to distinguish three different things:
1. Backup
Does the backup job actually complete correctly, both locally and remotely?
2. Restore
Can we reliably restore an account from that backup when we actually need it?
This is probably the most important question.
A backup that reports "completed successfully" is only useful if the corresponding restore has also been tested and is reliable.
Can CWP clarify which restore scenarios are currently tested and considered production-ready?
3. Email reporting
This is a separate issue that I have personally reported.
Even when a backup job runs, the administrator needs reliable reporting:
- local backup status;
- remote backup status;
- successful accounts;
- failed accounts;
- warnings/errors;
- and reliable notification emails.
If the backup runs but the notification is missing or incomplete, the administrator does not have reliable visibility of the backup status.
This is why I don't think "use an external backup solution" answers the question.
Administrators can certainly use external backup systems, and many of us do.
But CWP also provides a Backup/Restore system, and it is reasonable to ask what its current production status actually is.
The same applies to the update process.
I understand that emergency security releases can sometimes require accelerated development and reduced testing.
However, after such releases, it becomes even more important to clearly communicate:
- what changed;
- what was tested;
- what could not be tested;
- what regressions are known;
- and what has subsequently been fixed.
The CWP changelog currently does not provide enough detail for an administrator to reconstruct this information reliably.
So I would like to ask the CWP team directly:
Could you please provide an updated status for the issues raised in this thread?
Even a simple table would be enough:
Code: [Select]
Component Status Fixed in Notes
--------------------------------------------------------
Backup Stable / Beta x.x.x ...
Restore Stable / Beta x.x.x ...
Reporting Open / Fixed x.x.x ...
UI Open / Fixed x.x.x ...
ModSecurity Open / Fixed x.x.x ...
CSF/Firewall Open / Fixed x.x.x ...
YUM Manager Open / Fixed x.x.x ...
PHP Selector Open / Fixed x.x.x ...
It does not need to be perfect.
What matters is having a clear reference that allows administrators to understand:
what is fixed, what is not fixed, what is still beta, and what requires attention before updating a production server.
That was the reason for opening this thread in the first place.
I would really appreciate a technical response from the CWP team so that we can turn this into something useful for the whole community.
38
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by cyberspace on August 15, 2026, 09:38:33 AM »Did you check the .htaccess file? Make sure your sites don’t contain any suspicious or obfuscated code. This could also happen if your website loads files or resources from a compromised third-party site.
If you identified the user agents that trigger the redirect, try searching the web server configs and website files for those user agents.
If you identified the user agents that trigger the redirect, try searching the web server configs and website files for those user agents.
39
Backup / Error/bug when starting a backup
« Last post by André Bastos on August 14, 2026, 08:45:25 PM »What used to work has stopped working for no apparent reason. Does anyone have a solution? This is disrupting the smooth operation of our processes.
When clicking RUN to start the manual backup of some accounts before removing them, we now get the following error:
Error...!
You must activate the backup first and then run it
When clicking RUN to start the manual backup of some accounts before removing them, we now get the following error:
Error...!
You must activate the backup first and then run it
40
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by xelavalle on August 14, 2026, 10:25:55 AM »Thanks for your replies; they are valuable for understanding the issue.
It turns out to be the same case Geodim described; I followed the steps outlined on his blog, and the problem was resolved. Many thanks!
That leads me to ask: isn't CWP supposed to show an alert if a system file is modified? Does the fact that it didn't show one mean something else has been altered?
It turns out to be the same case Geodim described; I followed the steps outlined on his blog, and the problem was resolved. Many thanks!
That leads me to ask: isn't CWP supposed to show an alert if a system file is modified? Does the fact that it didn't show one mean something else has been altered?
