OK - we've come up with this (based on your post Blair):

In packages/rules/container.cfc we've added a CFIF to check that you
have generic webtop permissions before allowing the createData method
to be called... seems to work... can you see any problems with this
approach?

        <cffunction name="createData" access="public" returntype="any"
output="false" hint="Creates an instance of a container object.">
                <cfargument name="stProperties" type="struct" required="true"
hint="Structure of properties for the new container instance.">
                <cfargument name="parentobjectid" type="string" required="No"
default="" hint="The objectid of the object that instantiated the
container.  Should only be set if the container is unique to that
instance.  Will enable clean-up of unused containers when the parent-
object is deleted.">
                <cfargument name="dsn" type="string" required="false"
default="#application.dsn#">
                <cfset var stNewObject = structNew()>

                <cfif application.security.checkPermission("Admin")>

                        <cfscript>
                                stNewObject = 
super.createData(arguments.stProperties);
                                if (len(arguments.parentObjectid))
        
createDataRefContainer(objectid=arguments.parentobjectid,containerid=stNewObject.objectid);
                        </cfscript>

                </cfif>

                <cfreturn stNewObject>
        </cffunction>


On Feb 25, 9:07 am, Colin Jones <[email protected]> wrote:
> Ah - so you're saying that simply viewing the page (as a public user)
> forces farcry to create empty containers if there are none against the
> page in the DB, and as we haven't got to that stage in the draft ->
> approved process it ends up getting the empty containers instead?
>
> Our problem is that we aren't immediately going to be able to move to
> 6.0, however we need something to patch this in the meantime.  Any
> idea where this code is triggered in 5.2.3!?   Could we disable it
> somehow there?  :)
>
> On Feb 24, 10:30 pm, Blair McKenzie <[email protected]> wrote:
>
> > Hi Colin
>
> > This is an issue we've had as well. It happens because FarCry creates empty
> > containers for pages that don't have any in the DB. While FarCry is busy
> > migrating the draft page to live ... for a very brief moment the page is
> > empty. We fixed the problem in FC6 by removing the automatic creation
> > process. Now containers are ONLY created if a user views a page in rule
> > editing mode.
>
> > Blair
>
> > On Thu, Feb 25, 2010 at 2:46 AM, Colin Jones <[email protected]> wrote:
> > > Thanks Chris - I think we have also narrowed it down to core as
> > > well...
>
> > > We've tried two independent websites using FarCry - totally different
> > > projects on different servers, the other one running 5.2.7 of core,
> > > and have been able to successfully replicate this behaviour simply by
> > > loading requests on the page while approving in the webtop.  Sometimes
> > > you have to go through the 'draft/approve' loop a few times before it
> > > happens, but it doesn't take long before you lose the rule containers
> > > on the page.
>
> > > This is obviously a very serious core bug, as changing a page
> > > (particularly the homepage) on a site with heavy traffic means that
> > > you can lose every rule on it - clearly something that is likely to
> > > affect the homepage more often than others by the nature of traffic
> > > patterns.  Editing rules themselves has no effect, and you can happily
> > > change those without this behaviour manifesting.  Seems to be just
> > > moving a draft version of the page itself to approved causes it -
> > > which seems to link it back to that bug again... :(
>
> > > Problem is this is severely knocking the confidence of our editing
> > > team in the system... they are already printing out copies of things
> > > because they feel that it isn't reliable!
>
> > > (PS: Thanks for the info on caching, but as performance hasn't been a
> > > problem, we're not pursuing that at the moment - this however we have
> > > to find some resolution to!)
>
> > > On Feb 24, 10:32 am, Chris Kent <[email protected]> wrote:
> > > > Colin,
>
> > > > Yes, adding something like
> > > >     * @@cachStatus: 1
> > > >     * @@cacheTimeout: 5
> > > > is simple caching, refreshing after 5 minutes
>
> > > > But for dynamic content you can also set the cache to check for new
> > > > type content and then flush the cache if there is something new to
> > > > display. Check out @@cacheTypeWatch, Geoff had a nice quick demo of it
> > > > working on the AUS Winter Olympic site at last weeks cfmeetup Farcry 6
> > > > presentation -
> > >http://www.meetup.com/coldfusionmeetup/pages/Recordings_of_the_ColdFu...
> > > > &http://carehart.org/cfmeetuprecordings/20100218_CF%20Meetup_%20FarCry.
> > > ..
> > > > for the downloadable flv.
>
> > > > As for fixing the conflict between setting content to approved and
> > > > grabbing content for display - this will require a fix within farcry
> > > > core code.
>
> > > > Chris.
>
> > > > On Feb 24, 10:15 am, Colin Jones <[email protected]> wrote:
>
> > > > > We're not using webskin caching - just objectbroker caching of the
> > > > > database requests.
>
> > > > > Webskin caching caused us other problems with dynamic content, so we
> > > > > never enabled it. (I'm assuming you mean View Caching described
> > > herehttp://docs.farcrycms.org/display/FCDEV50/UNIT+08+-+Object+Broker,+Vi.
> > > ..
> > > > > )
>
> > > > > We have narrowed it down to that final "submit" for approval on the
> > > > > screen that asks you for the approval comment.  If we run without load
> > > > > up to that point, then load the page requests for that page just prior
> > > > > to pressing the final submit, it loses all the rules on the page.
>
> > > > > On Feb 24, 9:31 am, Chris Kent <[email protected]> wrote:
>
> > > > > > Colin,
>
> > > > > > Sounds like some form of locking should be put in place - i.e. do 
> > > > > > not
> > > > > > allow nj:display to get content item whilst set status to approved
> > > > > > (statustoapproved) process is in in progress for that same item.
>
> > > > > > Are you using webskin chaching, if not it might be worth looking 
> > > > > > into
> > > > > > if you are not, The cached version of the webskin may (have not
> > > > > > tested) still be available for display whilst the content item is
> > > > > > being approved. Not sure, without looking, what the sequence of
> > > events
> > > > > > are when approving content - i.e. does the full DB update complete
> > > > > > before the webskin cache is cleared?
>
> > > > > > Chris.
>
> > > > > > On Feb 24, 8:37 am, Colin Jones <[email protected]> wrote:
>
> > > > > > > Hi we've just encountered a major problem when trying to edit our
> > > > > > > (busy) homepage.  We have various rule containers on there, but if
> > > we
> > > > > > > create a draft version - even just to change some metadata on the
> > > > > > > page, then send it to approved we're frequently losing several
> > > rules
> > > > > > > from the page randomly.
>
> > > > > > > This appears to be directly related to this bughttp://
> > > bugs.farcrycms.org/browse/FC-523
> > > > > > > which does not appear to have a fix.  We are currently running
> > > 5.2.3
> > > > > > > of farcry.
>
> > > > > > > We can replicate it every time on dev and test by running jakarta
> > > > > > > jmeter against the page to simulate continual requests.  If the
> > > page
> > > > > > > is edited while the page is being requested continually any or all
> > > the
> > > > > > > rules on the page end up disappearing.  Obviously this is a major
> > > > > > > problem for us and the editors, as we could be randomly losing
> > > content
> > > > > > > all over the site, and people may not even notice it's gone
> > > > > > > immediately.
>
> > > > > > > If anyone has any ideas on how to fix this they'd be greatly
> > > > > > > appreciated!
>
> > > > > > > Cheers,
> > > > > > > Colin.
>
> > > --
> > > You received this message cos you are subscribed to "farcry-dev" Google
> > > group.
> > > To post, email: [email protected]
> > > To unsubscribe, email: 
> > > [email protected]<farcry-dev%[email protected]>
> > > For more options:http://groups.google.com/group/farcry-dev
> > > --------------------------------
> > > Follow us on Twitter:http://twitter.com/farcry
>
>

-- 
You received this message cos you are subscribed to "farcry-dev" Google group.
To post, email: [email protected]
To unsubscribe, email: [email protected]
For more options: http://groups.google.com/group/farcry-dev
--------------------------------
Follow us on Twitter: http://twitter.com/farcry

Reply via email to