- Issue created by @dpierre
- π¨π¦Canada Liam Morland Ontario, CA π¨π¦
Can you use
git bisect
to determine which commit is causing this? If you revert that commit, does the problem go away? The only way to determine the immediate cause is to read the PHP logs and get that information.
- πΊπΈUnited States jrockowitz Brooklyn, NY
I am suspecting you need to run database updates and/or clear your cache.
@see π Crash after update request Active - π«π·France dpierre
Hi cilefen,
how can I read the PHP logs ? I cannot connect to the site. Is there a "PHP logs file" stored somewhere in the web site directories ? I browse through it, but did not find any evidence of such a file.Hi jrockowitz,
using ssh, I have run "php update.php" in the web site directory (I have modified the settings.php to be able to run the update.php without being logged as admin).
After this, the situation is still the same. I cannot connect to the site."Clear your cache" ? What do you mean ? Which cache ? Where is it located ?
Thanks for your support.
The location of PHP logs depends on your web server environment and setup. Consult its documentation for information. Logs are not normally stored in web site directories for security reasons.
Drupal.org documentation has an article titled Clearing the Cache β .
- π«π·France dpierre
Thanks to both of you,
I feel now less ignorant ! I used the "rebuild.php" script and it worked !
I run the script through ssh.from : https://www.drupal.org/docs/user_guide/en/prevent-cache-clear.html β
Using the rebuild script
Open settings.php (/sites/default/settings.php) in any plain text editor. Add this line to the end of the file and save it:
$settings['rebuild_access'] = TRUE;
Visit http://www.example.com/core/rebuild.php in your browser (where www.example.com is your siteβs URL). After a short pause, you should be redirected to the home page of your site, and the cache should be rebuilt.
Open settings.php (/sites/default/settings.php) in a text editor. Find the line you added with $settings[rebuild_access], remove this line, and save the file.
ISo as a conclusion :
- the "rebuild.php script" cured the problem. Fine !
- but eliminating the source of the problem (webform 6.3.0-beta 3 update) would mobillize less effort.
- I will not upgrade production sites for the moment. Am I rigt ? I am glad to have helped! Reminder: Webform 6.3 is beta software right now and rebuilding the cache should part of your deployment steps.
Anyway, I am marking this as a duplicate of π Crash after update request Active in the absence of specific logs.