It definitely seems to work when changed in core. Extending into the project doesn't work at the moment - it appears to be because the createData method in container.cfc refers to super.createData() - If we simply take a copy of the function from core we end up with it simply calling it's parent - the original createData() in core! And as there is no super.super... supported in CF we're trying to see if there is another way...
On Feb 25, 11:07 am, Blair McKenzie <[email protected]> wrote: > I'm no expert on this bit of FarCry, but it sounds pretty safe. I think Matt > made his change further up the processing chain to reduce processing as much > as possible, but if you aren't a container guru like him your approach is > probably safer. > > Keep in mind that you don't have to make the change in core - you > *should*be able to extend container into your project and override the > createData > function there. > > Keep us posted. I'm interested in knowing if this is a solid solution we can > recommend to others in the same situation. > > Blair > > On Thu, Feb 25, 2010 at 9:12 PM, Colin Jones <[email protected]> wrote: > > 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]> > > <farcry-dev%[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]<farcry-dev%[email protected]> > > For more options:http://groups.google.com/group/farcry-dev > > -------------------------------- > > Follow us on Twitter: > > ... > > read more » -- 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
