For the record, we're a mid-size organization, building a modern product on
PHP 7 with a PSR-based stack.
We've shunned template engines and rely heavily on short open tags and
alternative control-structures - mainly because we insist on static
analysis and IDE support, which we get by manually ty
On 25/03/2019 16:38, Andrey Andreev wrote:
>
> OK, so why not flip it and make it always available instead? I'm aware
> of the potential XML conflict, but I've personally never seen it, so
> to me that looks like the lesser evil compared to a massive BC break.
I slightly lean towards removing s
Hi,
On Mon, Mar 25, 2019 at 5:16 PM Johannes Schlüter
wrote:
>
> On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote:
> >
> > As we stand now, code using short open tags works when those tags are
> > enabled. As we'd stand in the future, that code would not work.
> > That
> > level of BC break
On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote:
>
> As we stand now, code using short open tags works when those tags are
> enabled. As we'd stand in the future, that code would not work.
> That
> level of BC break requires a strong justification.
The code would not simply "not work" but
On Tue, Mar 12, 2019 at 11:57 AM Stanislav Malyshev
wrote:
> > I'm currently going through the PHP doc to remove mentions of PHP 4
> > and stumbled upon the short_open_tag ini directive [1] which only
affects
> > the availability of ` > From my understanding, the ` > so maybe we should deprecate P
Hello,
On Sat, 16 Mar 2019 at 03:57, Morgan Breden wrote:
>
> >If you want to go further, dropping the PHP tag altogether would be nice,
> since it would prevent context switching between PHP/HTML/JS/whatever.
> >That would force Wordpress to update their whole
> code base. >:{)>
>
> I wholehearte
On Sat, 16 Mar 2019 at 03:44, Kenneth Ellis McCall
wrote:
> G. P. B. wrote:
> > currently going through the PHP doc to remove mentions of PHP 4
> > and stumbled upon the short_open_tag ini directive [1] which only affects
> > the availability of ` > From my understanding, the ` directive,
> > so
>If you want to go further, dropping the PHP tag altogether would be nice,
since it would prevent context switching between PHP/HTML/JS/whatever.
>That would force Wordpress to update their whole
code base. >:{)>
I wholeheartedly support this initiative but I do not see it going through
without a
G. P. B. wrote:
currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of `
I would like to see that. "Question mark equals what?".
If you want to go further, dropping the PHP tag altogether woul
On Fri, 15 Mar 2019 at 17:03, Rowan Collins wrote:
> On Fri, 15 Mar 2019 at 15:56, G. P. B. wrote:
>
> > However, I'm not sure of the behavior if someone sets this behavior
> within
> > a file/class
> > does this only affect this specific instance or is it globally?
> >
>
> Not all settings can
On Fri, 15 Mar 2019 at 15:56, G. P. B. wrote:
> However, I'm not sure of the behavior if someone sets this behavior within
> a file/class
> does this only affect this specific instance or is it globally?
>
Not all settings can be altered with ini_set; this one is listed at
http://php.net/manual/
Just gonna do general reply instead of pointing at specific points.
But as it has been pointed out using short tags makes the code less
portable,
which IMO isn't ideal.
I personally don't tinker with INI settings withing PHP with `ini_set` as
IMHO if you
need to change them it should be done in t
On Di, 2019-03-12 at 23:50 +0100, Peter Kokot wrote:
>
> > Which would be good - as all those things make writing portable
> > code
> > harder.
> >
> > $ echo '' | php
> >
> > Is a valid program, which will behave vastly different based on the
> > ini
> > setting.
>
> In reality if developer
Hello,
On Tue, 12 Mar 2019 at 17:57, Johannes Schlüter wrote:
>
> On Di, 2019-03-12 at 15:53 +, Rowan Collins wrote:
> > On Tue, 12 Mar 2019 at 13:28, G. P. B.
> > wrote:
> >
> > >
> > > I was more going along the lines of removing short tags altogether
> > > with the
> > > ini setting as th
On Di, 2019-03-12 at 15:53 +, Rowan Collins wrote:
> On Tue, 12 Mar 2019 at 13:28, G. P. B.
> wrote:
>
> >
> > I was more going along the lines of removing short tags altogether
> > with the
> > ini setting as they are not available out of the box except if you
> > use a
> > special compile
Hi!
> I'm currently going through the PHP doc to remove mentions of PHP 4
> and stumbled upon the short_open_tag ini directive [1] which only affects
> the availability of ` From my understanding, the ` so maybe we should deprecate PHP's short tag altogether?
Why? What would it improve for people
On Tue, 12 Mar 2019 at 13:28, G. P. B. wrote:
> I was more going along the lines of removing short tags altogether with the
> ini setting as they are not available out of the box except if you use a
> special compile flag.
>
I don't really follow this reasoning: if we removed every feature whic
On Tue, 12 Mar 2019 at 14:43, Christoph M. Becker wrote:
> On 12.03.2019 at 14:27, G. P. B. wrote:
>
> > I was more going along the lines of removing short tags altogether with
> the
> > ini setting as they are not available out of the box except if you use a
> > special compile flag.
>
> To my k
On 12.03.2019 at 14:27, G. P. B. wrote:
> I was more going along the lines of removing short tags altogether with the
> ini setting as they are not available out of the box except if you use a
> special compile flag.
To my knowledge, short_open_tag=1 *always* enables short open tags,
regardless o
I was more going along the lines of removing short tags altogether with the
ini setting as they are not available out of the box except if you use a
special compile flag. However, I didn't know they were used with template
engines but wouldn't they just use `
On Tue, 12 Mar 2019 at 12:15, Alexandru Pătrănescu wrote:
>
> Hi,
>
> I guess that `short_open_tag` ini settings can be deprecated/removed.
> But that would mean that short open tags will be always available, not that
> it will be removed.
>
> Regards,
> Alex
Oh, the main idea is to remove the in
Hi,
I guess that `short_open_tag` ini settings can be deprecated/removed.
But that would mean that short open tags will be always available, not that
it will be removed.
Regards,
Alex
On Tue, Mar 12, 2019 at 12:39 PM Rowan Collins
wrote:
> On Tue, 12 Mar 2019 at 10:12, Peter Kokot wrote:
>
>
On Tue, 12 Mar 2019 at 10:12, Peter Kokot wrote:
>
> PHP based template engines today most likely use only because of this topic today exactly. Possibility of being deprecated
> :) I think the short opening tags are good to go so things are more
> simple.
>
A quick search of the list archives
Hello,
On Tue, 12 Mar 2019 at 10:51, Rowan Collins wrote:
>
> On Mon, 11 Mar 2019 at 20:06, G. P. B. wrote:
>
> > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether?
> >
>
>
> I think when that's been proposed in the past, people have said they like
> it for us
On Mon, 11 Mar 2019 at 20:06, G. P. B. wrote:
> From my understanding, the ` so maybe we should deprecate PHP's short tag altogether?
>
I think when that's been proposed in the past, people have said they like
it for use in simple templates, often along with the "alternative control
structures"
Hello internals,
I'm currently going through the PHP doc to remove mentions of PHP 4
and stumbled upon the short_open_tag ini directive [1] which only affects
the availability of `From my understanding, the `https://secure.php.net/manual/en/ini.core.php#ini.short-open-tag
26 matches
Mail list logo
