Any plans to tag a 1.5.2 release any time soon?

[stephenrs]

We've been pulling updates from the 1.5 branch for many months now
(currently getting 1.5.1 updates), praying for the day when I can lock
our svn:externals definition to a latest/current stable
release...because the branch updates far too frequently introduce
instability into our system. Locking to the 1.5.1 tag is not an option
at this point. Lots of other dev tasks to take care of, so we need to
get off of the Apostrophe development treadmill.

Speaking of instability...we're currently unable to create new blog
posts (apostropheBlogPlugin), showing a console error of
aInput.aSetCursorPosition is not a function. (line 772 in
aControls.js).

...and as I write this, one of my devs just showed me this: Fatal
error: Class 'DOMDocument' not found in /var/www/vhosts/something/
plugins/apostrophePlugin/lib/toolkit/aHtml.class.php on line 227

An updated aHtml.class.php just came across the svn up wire today, so
it looks like we can't create/edit content items anymore either.

I know the risks of pulling updates from an active line of
development, so shame on me...and I appreciate the fast pace of
development of Apostrophe. I guess I just wish a bit more care was
taken on the Punk'd QA side when commits go into the repo (like
running unit or other automated tests on new code to make sure basic
functions still work), and I'm used to the stability of other Symfony
plugins that I've been happily pulling from trunk for years...or I'm
hoping the current line of Apostrophe dev will get stable...then get
tagged.

Any suggestions on any of this, including the two errors I mention
above would be very much appreciated.

Thanks.

[Tom Boutell]

DOMDocument has been a prerequisite for years, so don't go complaining
about that one (:

servercheck.php will tell you what you're missing there.

I'll look at the other issues you mentioned.

We made some fixes to a.js this week, intended to fix poorly
documented old code, but they should have been more thoroughly QA'd.

We do understand it is important to change the 1.5 branch of the core
plugins less often as it is supposed to be stable. Going forward
changes ought to be bugfixes, refactorings of partials so we don't
have to override the whole thing, or additions of Symfony events so
things can be extended elsewhere. Darn little else.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[Tom Boutell]

On Wed, Feb 1, 2012 at 2:12 PM, stephenrs <ssgr...@gmail.com> wrote:

> Speaking of instability...we're currently unable to create new blog
> posts (apostropheBlogPlugin), showing a console error of
> aInput.aSetCursorPosition is not a function. (line 772 in
> aControls.js).

Are you doing these tests in a fresh checkout of the 1.5 sandbox?

This error is not happening in my tests. aSetCursorPosition is added
to jQuery by line 1003 of aControls.js.

> ...and as I write this, one of my devs just showed me this: Fatal
> error: Class 'DOMDocument' not found in /var/www/vhosts/something/
> plugins/apostrophePlugin/lib/toolkit/aHtml.class.php on line 227

You're missing a standard PHP extension that has always been required
for Apostrophe, see servercheck.php

> An updated aHtml.class.php just came across the svn up wire today, so
> it looks like we can't create/edit content items anymore either.

I am able to add and edit rich text slots in a freshly updated
sandbox. If that is not the problem you are experiencing please be
specific.

[stephenrs]

Tom, thanks for your reply, please see mine below...

On Feb 1, 1:16 pm, Tom Boutell <t...@punkave.com> wrote:
> DOMDocument has been a prerequisite for years, so don't go complaining
> about that one (:

Hmm, we've been using Apostrophe since the mid-Alpha days (>18
months), and this has never come up before. Has something changed
recently that might trigger this problem? FWIW we've more than a few
times had to deal with classes getting shuffled around and the class
hierarchy getting busted - this smells more like that.

>
> servercheck.php will tell you what you're missing there.
>

We don't have a servercheck in our distrib (although a quick search
found me this: http://trac.apostrophenow.org/ticket/507), but a
phpinfo() shows me that we have 'XML support - active'. I'd be shocked
if we could have used Apostrophe for this long without it...but please
tell me if I should be shocked.

> I'll look at the other issues you mentioned.
>
> We made some fixes to a.js this week, intended to fix poorly
> documented old code, but they should have been more thoroughly QA'd.
>
> We do understand it is important to change the 1.5 branch of the core
> plugins less often as it is supposed to be stable. Going forward
> changes ought to be bugfixes, refactorings of partials so we don't
> have to override the whole thing, or additions of Symfony events so
> things can be extended elsewhere. Darn little else.

This would be a very much welcomed change in approach. I didn't even
realize the 1.5 branch was supposed to be stable - it unfortunately
feels much more like a bleeding edge nightly.

[Tom Boutell]

DOMDocument is not ours at all - Google it (: It's standard PHP fare,
unless one of your builds doesn't have it. Thus servercheck.php.
Symfony 2 has one too, because unfortunately you can disable almost
anything in PHP ):

servercheck.php is included in the sandbox. I suggest you do some
testing with a fresh checkout of the sandbox.

It would also help to make sure you're doing a symfony cc every time
you svn up our stuff, and that the svn paths to all plugins used in
our sandbox are the same in your project.

[stephenrs]

Thanks again, see below...

On Feb 1, 1:21 pm, Tom Boutell <t...@punkave.com> wrote:

> On Wed, Feb 1, 2012 at 2:12 PM, stephenrs <ssgro...@gmail.com> wrote:
> > Speaking of instability...we're currently unable to create new blog
> > posts (apostropheBlogPlugin), showing a console error of
> > aInput.aSetCursorPosition is not a function. (line 772 in
> > aControls.js).
>
> Are you doing these tests in a fresh checkout of the 1.5 sandbox?
>

Not to whine too much, but this is almost always the first line of
questioning when something goes wrong...I don't doubt that a pristine
checkout of the sandbox will work...but this fact unfortunately serves
no purpose for my production environment, nor is it feasible to set up
a new sandbox for troubleshooting every time Apostrophe breaks due to
deciding to risk it and omitting --ignore-externals...

It would be great if you guys kept your own pseudo-production
'sandbox' that had an svn:externals that pulls from the active
Apostrophe branch...then you'd likely see some of the craziness that
I've been seeing oh these many months...not least of which was the
jump to jquery-1.7.1...again FWIW, upgrading jquery is on our schedule
for the next dev sprint a month or so from now, and 1.7.1 currently
introduces blocker conflicts to our system...so, we've spun off a
separate instance of our system that is only for CMS updates (and is
broken for many other things), because Apostrophe now requires
1.7.1...and I'm currently borrowing from the syncContent plugin to
reduce the headache caused by this...

> This error is not happening in my tests. aSetCursorPosition is added
> to jQuery by line 1003 of aControls.js.
>

Yes, I see aSetCursorPosition() in aControls.js and have no idea yet
why this error would appear...guessing some js is getting loaded out
of order or something...

> > ...and as I write this, one of my devs just showed me this: Fatal
> > error: Class 'DOMDocument' not found in /var/www/vhosts/something/
> > plugins/apostrophePlugin/lib/toolkit/aHtml.class.php on line 227
>
> You're missing a standard PHP extension that has always been required
> for Apostrophe, see servercheck.php
>
> > An updated aHtml.class.php just came across the svn up wire today, so
> > it looks like we can't create/edit content items anymore either.
>
> I am able to add and edit rich text slots in a freshly updated
> sandbox. If that is not the problem you are experiencing please be
> specific.

My specific problem is that I'm managing development on a growing SAAS
system that has a little bit of public site content (that I'm still
hoping one day Apostrophe will keep out of my hair), and we svn upped
today - and adding/editing rich text slots stopped working :)

I'll look more closely to see if something on our end of the equation
could have gotten jiggered loose...

As always, thanks for your responsiveness.

[Geoff DiMasi]

You should not need to use jquery 1.7.1. It should be turned off with a flag by default. You have to turn it on specifically.

[stephenrs]

My bad...It turns out that the dom extension wasn't actually getting
loaded...now that it is, we're able to add/edit content again :)

Still have the mysterious JS error though...I'll keep looking....

[Tom Boutell]

To clarify what Geoff said, you don't have to turn off jquery 1.7 with
a flag. It is not loaded by default, period. We just have it there in
case we choose to enable it in a project. 1.4.3 is still used by
default and is still present in the plugin.

[stephenrs]

Hmm, a few days ago we started getting a JS error complaining about a
nonexistent function a.replace (or some such) when we clicked save on
a rich text slot. I remembered seeing jquery-1.7.1.js get added to the
repo on a recent svn up, so I took a stab in the dark and swapped it
in for our current version of jquery. Without any other changes, the
error went away and we were then able to add/edit slots again...

Our base version is 1.4.4 (I know, we're a bit behind the curve)...

[stephenrs]

Ok, wrapping this up...

The JS error on Saving new blog posts was being caused by jquery
getting loaded a second time by the jQueryReloaded plugin, which was
breaking things in aControl.js. Now that this is cleaned up, we can
create new blog posts again.

Thanks for your help and putting up with my venting (it's been one of
those weeks), and hopefully some of my commentary resonates as
legitimate/constructive suggestions.

In any case, back to the original topic: any plans to tag a stable
1.5.2? It would be much appreciated to be able to lock onto a stable
(newish) release, and certainly make this developer/manager's life
much less uncertain, and maybe other folks with actively developed
production systems as well. Maybe most users are building on top of
Apostrophe, but for some of us Apostrophe is just one part of a larger
(and distributed) system.

Thanks

[Tom Boutell]

We are a bit overdue to tag a stable release it is true. We don't have
to do anything more dramatic than tag it after all (:

--

[stephenrs]

Set me up with a shell account, and I'll happily pull my own weight on
this one ;)

[stephenrs]

...or a rw svn acct will do ;)

[Tom Boutell]

I tagged apostrophePlugin and apostropheBlogPlugin 1.5.2 in svn this morning.

[stephenrs]

@Tom, thanks for this. Recently returned from vacation and happened to
poke around in the repo and noticed the new tags - gives me and my
team some peace of mind.

On Feb 3, 10:12 am, Tom Boutell <t...@punkave.com> wrote:
> I tagged apostrophePlugin and apostropheBlogPlugin 1.5.2 in svn this morning.
>
>
>
>
>
>
>
>
>
> On Wed, Feb 1, 2012 at 11:19 PM,stephenrs<ssgro...@gmail.com> wrote:
> > ...or a rw svn acct will do ;)
>

> > On Feb 1, 10:14 pm,stephenrs<ssgro...@gmail.com> wrote:
> >> Set me up with a shell account, and I'll happily pull my own weight on
> >> this one ;)
>
> >> On Feb 1, 6:57 pm, Tom Boutell <t...@punkave.com> wrote:
>
> >> > We are a bit overdue to tag a stable release it is true. We don't have
> >> > to do anything more dramatic than tag it after all (:
>