Hi,
I logged as admin to Projeqtor 12.3.1, then switched to new interface. I have now the "Loading" spinning gear for an hour. Tried to close the browser, cleaned up cache, with no success. In a private browser window, the problem persists. As a regular (LDAP) user, there is no problem.
Thanks for any help,
Regards,
Xavier
In addition, I have this in my log file, dunno if it is related :
2025-10-08 15:03:39.243 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.243 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.244 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.244 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.246 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database.
2025-10-08 15:03:39.246 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database.
2025-10-08 15:03:39.246 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.246 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.247 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.247 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.247 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.247 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.248 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.248 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.249 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.249 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:39.255 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database on table resource
2025-10-08 15:03:39.255 ** ERROR ** [V12.1.3] [1] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database on table resource
2025-10-08 15:03:47.268 ** ERROR ** [V12.1.3] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database.
2025-10-08 15:03:47.268 ** ERROR ** [V12.1.3] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database.
2025-10-08 15:03:47.301 ** ERROR ** [V12.1.3] Error on SqlElement to get 'dummy' for Class 'User' : field 'dummy' not found in Database.
2025-10-08 15:03:47.301 ** ERROR ** [V12.1.3] Error on SqlElement to get 'mustChangePassword' for Class 'User' : field 'mustChangePassword' not found in Database.
And strangely, this field is actually present in the database :
MariaDB [projeqtor]> select mustChangePassword from resource where name like "admin";
+--------------------+
| mustChangePassword |
+--------------------+
| 0 |
+--------------------+
1 row in set (0.000 sec)
Try and restart MariaDB and PHP/Apache.
Possibly some php caching issue.
Hi Babynus
Did it with no success...
Xavier
Unfortunately, some other users, perhaps all except me (why ?) experiment the "Loading" spinning gear
You have an issue in your migration process.
You say you logged on V12.3.1, but log file show V12.1.3.
I'm not a fortune teller, but I guess you did not migrate as advised : overwrite existing code with new one.
I think you created a new instance and tried to migrated it.
And I now you mismatch with DB, no ?
I did the upgrade as advised, overwriting files, fixing ownership, then login as admin.
This worked, and still works for my account.
I did not mess with the database. The log I provided is timestamped at the time of the upgrade, that's probably why it shows v12.1.3
But other accounts, including admin, cannot login.
Xavier
Do you have logs for connection rejections ?
Do users have errors in browser console ?
Here is attached the debug log. The connection is accepted, but the spinning gear is still there
A screenshot of the debug window of Firefox shows only some warnings (attached too)
Strange that no error is logged.
Do you reproduce the behavior with another borwser ?
Can you check the network tab in browser dev tools ?
Do all request return with code 200 ?
Same behaviour with Chromium. And in network tab i get all 200, except for main.php, which also returns 200 but says
(failed) net::ERR_INCOMPLETE_CHUNKED_ENCODING
I think I found the problem :
2025-10-15T15:40:45.470150+02:00 pr-wbs-supweb02 systemd-coredump[943172]: Process 942727 (php-fpm) of user 1003 dumped core.
Stack trace of thread 942727:
#0 0x00005648c2d92367 php_stream_url_wrap_http_ex.isra.0 (php-fpm + 0x392367)
#1 0x00005648c2d95957 php_stream_url_wrap_http (php-fpm + 0x395957)
#2 0x00005648c2dc36a0 _php_stream_open_wrapper_ex (php-fpm + 0x3c36a0)
#3 0x00005648c2d4bcef zif_file_get_contents (php-fpm + 0x34bcef)
#4 0x00007f0e464abb6c phar_file_get_contents (phar.so + 0x1cb6c)
#5 0x00005648c2e8a41c execute_ex (php-fpm + 0x48a41c)
#6 0x00005648c2e8ee45 zend_execute (php-fpm + 0x48ee45)
#7 0x00005648c2e19440 zend_execute_scripts (php-fpm + 0x419440)
#8 0x00005648c2dac7ca php_execute_script (php-fpm + 0x3ac7ca)
#9 0x00005648c2c42b33 main (php-fpm + 0x242b33)
#10 0x00007f0e4a6295d0 __libc_start_call_main (libc.so.6 + 0x295d0)
#11 0x00007f0e4a629680 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29680)
#12 0x00005648c2c44975 _start (php-fpm + 0x244975)
ELF object binary architecture: AMD x86-64
2025-10-15T15:40:45.491253+02:00 pr-wbs-supweb02 systemd[1]: systemd-coredump@268-943171-0.service: Deactivated successfully.
2025-10-15T15:40:46.154894+02:00 pr-wbs-supweb02 kernel: php-fpm[942725]: segfault at 90 ip 00005648c2d92367 sp 00007ffff0b4a700 error 4 in php-fpm[5648c2c00000+31f000] likely on CPU 0 (core 0, socket 0)
2025-10-15T15:40:46.155037+02:00 pr-wbs-supweb02 kernel: Code: 48 c7 84 24 d0 00 00 00 00 00 00 00 45 31 e4 48 c7 84 24 d8 00 00 00 00 00 00 00 0f 1f 84 00 00 00 00 00 80 7c 24 38 00 74 29 8b bc 24 90 00 00 00 48 85 ff 74 04 48 8b 7f 18 48 8b 54 24 48
2025-10-15T15:40:46.172624+02:00 pr-wbs-supweb02 systemd[1]: Started Process Core Dump (PID 943183/UID 0).
A colleague of mine traced the problem to
projeqtor/view/menuNewGuiLeft.php
if (ini_get('allow_url_fopen')) {
enableCatchErrors();
enableSilentErrors();
$ctx=stream_context_create(array('http'=>array('timeout' => 5))); <==== CRASH HERE
$ctx=getStreamContext(5);
$json = file_get_contents($urlPlugins,false,$ctx);
disableCatchErrors();
disableSilentErrors();
}
if (!$json) return $result;
which caused the coredump.
Setting
php_value[allow_url_fopen] = Off in php-fpm.d/projeqtor.conf seems to fix the problem.
It seems your server is not allowed to access the internet.
Disabling curl is a good solution to be sure projeqtor is not struck.
Note than on most cases, this will lead to a small latency (trying to get the remote result) but user will connect.
In your case, error level seems to crash the php instead of just rizing an error.

