[wp-hackers] Need help upgrading CG-Related plugin to 1.3...

[Dennis Williamson]

Oh. Duhrrr. The first ternary falls through at the colon. I was carrying it 
through to the concatenation. Maybe I knew that, but I I'll just say that I 
"missed" it. I never use ternaries because of readability issues - so "use 
it or lose it". I should have translated the ternary to an if-then-else for 
myself so I could see it better.

I'm really sorry for the argument.

Can the second isset() be dropped thus relying solely on the !empty()? What 
about dropping the ternaries altogether and, assuming also omitting the 
second isset(), and having:

         // Fix for IIS, which doesn't set REQUEST_URI
         if (!isset($_SERVER['REQUEST_URI'])) {
                 $_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME']);
                 if (!empty($_SERVER['QUERY_STRING']))
                         $_SERVER['REQUEST_URI'] .= '?' . 
$_SERVER['QUERY_STRING'];
         }

Then it's obvious that R_U isn't touched except when it's not set (which 
sort of addresses David Chait's objection about touching http/PHP globals). 
And no terns are harmed...well, you get the idea.

My apologies for obsessing on this.

Dennis

At Wednesday 10/27/2004 12:22 AM, you wrote:
>On Tue, 2004-10-26 at 23:55 -0500, Dennis Williamson wrote:
> > So in 1.59 and prior the code path that would produce R_U.?.Q_S was never
> > executed?
> >
> > $_SERVER['REQUEST_URI'] = ( isset($_SERVER['REQUEST_URI']) ?
> > $_SERVER['REQUEST_URI'] : $_SERVER['SCRIPT_NAME'] . ((
> > isset($_SERVER['QUERY_STRING']) ? '?' . $_SERVER['QUERY_STRING'] : '')));
> >
> > The TRUE clause in the first ternary statement appended to the TRUE clause
> > in the second.
>
>
>This is why I don't like nested ternarys.  The code path that produces
>R_U.?.Q_S is executed only if R_U isn't set in the first place.  If it
>is set, the logic boils down R_U = R_U.  Nothing after the first colon
>is executed.  It just assigns R_U back to itself.  The logic in 1.59
>worked fine, except that an empty but set Q_S would result in R_U? on
>IIS.  When I fixed that and broke out the logic into a more readable
>form, I screwed it up because I forgot to bracket the whole thing in an
>isset test on R_U.  It should be unscrewed now.
>
>Ryan
>
> > At Tuesday 10/26/2004 11:31 AM, you wrote:
> > >On Tue, 2004-10-26 at 08:46 -0500, Dennis Williamson wrote:
> > > > Ryan,
> > > >
> > > > I just saw your fix in version 1.61 of wp-settings.php. It behaves
> > > > differently than 1.59 and prior (and 1.60).
> > > >
> > > > In the 1.59 and earlier versions, if R_U was set and Q_S was set 
> you'd get
> > > > R_U.?.Q_S. The same is true with 1.60 (but with a test for Q_S being
> > > empty).
> > > >
> > > > With 1.61, on non-IIS (R_U is set), you get R_U by itself and never 
> get a
> > > > Q_S appended.
> > >
> > >1.61 should have the same logic as 1.59, where R_U is left alone if
> > >already set.   R_U as set be the server should contain the Q_S.  That's
> > >why David was seeing the Q_S twice with the broken 1.60.
> > >
> > >Ryan
> > >
> > >
> > >
> > >_______________________________________________
> > >hackers mailing list
> > >hackers at wordpress.org
> > >http://wordpress.org/mailman/listinfo/hackers_wordpress.org
> >
> >
> >
> >
> > _______________________________________________
> > hackers mailing list
> > hackers at wordpress.org
> > http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>
>
>_______________________________________________
>hackers mailing list
>hackers at wordpress.org
>http://wordpress.org/mailman/listinfo/hackers_wordpress.org