Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backported display_errors-handling to sf1 #328

Conversation

thirsch
Copy link
Collaborator

@thirsch thirsch commented Feb 19, 2024

This pr is a follow-up to #239.


Thanks for your review in the other pr, @alquerci. I tried to remember what we wanted to fix with it and it turns out, we never used the setting for any other value than "Off". Therefore the semantic we need is the same as what current symfony is doing.

The main reason for this change is to keep the results (especially ajax and api calls) clean from notices and warnings.

As I closed the other pr with deleting the branch on our fork quite some time ago, I had to create a new one.

@thirsch thirsch force-pushed the feature/port_display_errors_handling_in_debug_mode branch from c008cca to bed4638 Compare February 19, 2024 20:20
@thirsch
Copy link
Collaborator Author

thirsch commented Feb 19, 2024

Looks like php-cs-fixer rules require me to change something in the class although I haven't touched it?

@connorhu
Copy link
Collaborator

@thirsch Unfortunately, the cs-fixer is not smart enough. It can't just look at the syntax in the PR patch. On the other hand, it seems that the original intention of the current cs-fixer setting to search only in files affected by PR has been lost.

@connorhu
Copy link
Collaborator

connorhu commented Feb 19, 2024

The location marked by the cs-fixer is incorrect. That's the problem anyway:

--- /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
+++ /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
@@ -129,13 +129,13 @@
 
         // error settings
         if (!in_array(PHP_SAPI, array('cli', 'phpdbg', 'embed'), true)) {
-          ini_set('display_errors', 0);
+            ini_set('display_errors', 0);
         } elseif (
             !filter_var(ini_get('log_errors'), FILTER_VALIDATE_BOOLEAN)
             || ini_get('error_log')
         ) {
-          // CLI - display errors only if they're not already logged to STDERR
-          ini_set('display_errors', 1);
+            // CLI - display errors only if they're not already logged to STDERR
+            ini_set('display_errors', 1);
         }
         error_reporting(sfConfig::get('sf_error_reporting'));
 

@thirsch thirsch force-pushed the feature/port_display_errors_handling_in_debug_mode branch from bed4638 to 8bdc953 Compare February 20, 2024 07:33
@thirsch
Copy link
Collaborator Author

thirsch commented Feb 20, 2024

The location marked by the cs-fixer is incorrect. That's the problem anyway:

--- /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
+++ /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
@@ -129,13 +129,13 @@
 
         // error settings
         if (!in_array(PHP_SAPI, array('cli', 'phpdbg', 'embed'), true)) {
-          ini_set('display_errors', 0);
+            ini_set('display_errors', 0);
         } elseif (
             !filter_var(ini_get('log_errors'), FILTER_VALIDATE_BOOLEAN)
             || ini_get('error_log')
         ) {
-          // CLI - display errors only if they're not already logged to STDERR
-          ini_set('display_errors', 1);
+            // CLI - display errors only if they're not already logged to STDERR
+            ini_set('display_errors', 1);
         }
         error_reporting(sfConfig::get('sf_error_reporting'));
 

Thanks and sorry, must have been to late yesterday. No idea, why I used 2 instead of 4 spaces for the three lines.

@thirsch thirsch requested a review from thePanz February 20, 2024 07:49
@thirsch thirsch force-pushed the feature/port_display_errors_handling_in_debug_mode branch from 8bdc953 to de31a26 Compare February 20, 2024 08:55
@thirsch thirsch force-pushed the feature/port_display_errors_handling_in_debug_mode branch from de31a26 to b2097d5 Compare February 20, 2024 10:14
@thirsch
Copy link
Collaborator Author

thirsch commented Feb 20, 2024

The location marked by the cs-fixer is incorrect. That's the problem anyway:

--- /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
+++ /Users/connor/Work/FriendsOfSymfony1/symfony1/lib/config/sfApplicationConfiguration.class.php
@@ -129,13 +129,13 @@
 
         // error settings
         if (!in_array(PHP_SAPI, array('cli', 'phpdbg', 'embed'), true)) {
-          ini_set('display_errors', 0);
+            ini_set('display_errors', 0);
         } elseif (
             !filter_var(ini_get('log_errors'), FILTER_VALIDATE_BOOLEAN)
             || ini_get('error_log')
         ) {
-          // CLI - display errors only if they're not already logged to STDERR
-          ini_set('display_errors', 1);
+            // CLI - display errors only if they're not already logged to STDERR
+            ini_set('display_errors', 1);
         }
         error_reporting(sfConfig::get('sf_error_reporting'));
 

Thanks and sorry, must have been to late yesterday. No idea, why I used 2 instead of 4 spaces for the three lines.

Found it, our fork seems to use a pre-php-cs-fixer version with two instead of four spaces and I initially implemented it there.

@connorhu
Copy link
Collaborator

Found it, our fork seems to use a pre-php-cs-fixer version with two instead of four spaces and I initially implemented it there.

Two spaces? 😱 What an evil company!?

@thirsch thirsch force-pushed the feature/port_display_errors_handling_in_debug_mode branch from b2097d5 to 9ce2dcb Compare February 20, 2024 12:41
@thePanz thePanz merged commit 1b79957 into FriendsOfSymfony1:master Feb 20, 2024
5 checks passed
@thirsch thirsch deleted the feature/port_display_errors_handling_in_debug_mode branch February 20, 2024 13:08
@thirsch
Copy link
Collaborator Author

thirsch commented Feb 23, 2024

Hi @thePanz, this (and FriendsOfSymfony1/doctrine1@eeb1777) were the last changes I need to go back to the "official" release packages. Any plans for a new release of doctrine1 and symfony1? I'd like to avoid using dev-Tags on production system.

@thePanz
Copy link
Member

thePanz commented Feb 23, 2024

Hi @thePanz, this (and FriendsOfSymfony1/doctrine1@eeb1777) were the last changes I need to go back to the "official" release packages. Any plans for a new release of doctrine1 and symfony1? I'd like to avoid using dev-Tags on production system.

yes, I think we can tag the next releases 👍

Done!

  • SF1: v1.5.17
  • Doctrine1: v6.4.1

@connorhu
Copy link
Collaborator

connorhu commented Feb 23, 2024

One year nothing, now 2 versions in 2 weeks. A huge tempo.
Also: Now we're messing up @thirsch 's production systems if anything goes wrong. 😈

@thePanz
Copy link
Member

thePanz commented Feb 23, 2024

One year nothing, now 2 versions in 2 weeks. A huge tempo.

People asked, we delivered 😅

Now we're messing up @thirsch 's production systems if anything goes wrong. 😈

That's a good way to push for fixes? 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants