title: Laravel 5.3 - Query Builder starting with orWhere
body: <p>Recently Laravel released version 5.3.</p>
  
  <p>There are some upgrade instructions from 5.2 to 5.3 in the following link:
  <a href="https://laravel.com/docs/5.3/upgrade#upgrade-5.3.0" rel="nofollow noreferrer">https://laravel.com/docs/5.3/upgrade#upgrade-5.3.0</a></p>
  
  <blockquote>
    <p>Eloquent scopes now respect the leading boolean of scope constraints. For example, if you are starting your scope with an orWhere constraint it will no longer be converted to normal where. If you were relying on this feature (e.g. adding multiple orWhere constraints within a loop), you should verify that the first condition is a normal where to avoid any boolean logic issues.</p>
    
    <p>If your scopes begin with where constraints no action is required. Remember, you can verify your query SQL using the toSql method of a query:</p>
  </blockquote>
  
  <p>This seems to make things a bit harder, and the upgrade will only add limitations to it.</p>
  
  <p>We have an internal package, and to keep the code simple and as neat possible, there is a part that relies on starting a query with orWhere(), and makes use of this as well as the closure concept inside a recursive method.  As you know, recursive methods are best to keep it short and simple.</p>
  
  <p>According to the upgrade note now, it will for sure fail on Laravel 5.3</p>
  
  <p>I was just wondering if anyone knows the reason to why this behavior is being removed?</p>
  
  <p>Thanks!</p>
  
  <p><strong>Update:</strong></p>
  
  <p>I've migrated our system over to Laravel 5.3.  I confirm that this is only affected in Eloquent builder, and not in the Query Builder (formerly "Fluent Builder").</p>
  
  <p>Even the commit (which is a hell of a lotta changes) is only on Eloquent\Builder.
  <a href="https://github.com/laravel/framework/issues/14829" rel="nofollow noreferrer">https://github.com/laravel/framework/issues/14829</a></p>
  
  <p>Anyway, to be on the safe side, I do recommend to make the tweak accordingly.  That is what we did, though we know that it did not break our code (as of today).</p>