6.1.1 / Trunk - Handpicked rules erroring or ignoring "Select Objects"

[James Buckingham]

Hi again,

I've managed to hit quite a major bug to do with Handpicked Rules and the fact they don't seem to be saving the selections I'm making.

I've stripped the rule right back to the core versions and depending on what I do I get one of two things happen.....

1) I create a new rule. I fill out the form and select say two content type entries. The type & amount don't seem to matter.

These appear in the form and I then click save.

The container refreshes but is empty.

I go back in to edit, all my entries are still showing but the selected objects have vanished. They don't seem to be in the database either.

2) I edit an existing rule, one that was made before the upgrade, all the details are showing in the rules window fine but when I hit save I get this error:-

There was a problem with that last request!

Please push "back" on your browser or go back home

Error Details

Message	[objectid] is part of this table's primary key and must be included in stProperties
Exception Type	Application
Detail
Tag Context	C:\Inetpub\farcry\core\packages\dbgateways\BaseGateway.cfc (line: 267) C:\Inetpub\farcry\core\packages\dbgateways\BaseGateway.cfc (line: 147) C:\Inetpub\farcry\core\packages\dbgateways\BaseGateway.cfc (line: 330) C:\Inetpub\farcry\core\packages\lib\db.cfc (line: 504) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 923) C:\Inetpub\farcry\core\packages\rules\rules.cfc (line: 451) C:\Inetpub\farcry\core\tags\formtools\processFormObjects.cfm (line: 269) C:\Inetpub\farcry\core\tags\formtools\processFormObjects.cfm (line: 179) C:\Inetpub\farcry\core\tags\formtools\processFormObjects.cfm (line: 157) C:\Inetpub\farcry\core\tags\formtools\processFormObjects.cfm (line: 1) C:\Inetpub\farcry\core\packages\rules\rules.cfc (line: 289) C:\Inetpub\farcry\core\webskin\rules\editInPlace.cfm (line: 9) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 442) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 332) C:\Inetpub\farcry\core\webtop\conjuror\invocation.cfm (line: 152)

Doing a bit of Googling it looks like another user has raised a bug ticket for this as well.....
https://farcry.jira.com/browse/CMS-132

---

The fact that the handpick isn't working is a big issue for our Editor, probably to the point that we'd have to look at downgrade FarCry back to 5.2.3, which I'd rather not do.

Does anyone have any ideas what's causing this and of any potential fix? As I say I've taken a copy of trunk and the problem seems to be there as well.

Thanks again,
James

[Geoff Bowers]

Easiest fix is to simply write your own dedicated rule. Takes 10 minutes to build a hand picked rule for a specific content type. 

The current hand picked rule is complicated by the need to provide a potentially different view for each selected content item. But 90% of the time all the content items share the same view.... or you could always publish multiple rules in the same container.  All up I think the old skool hand picked rule probably needs to fall in a well and die.

-- geoff

http://www.daemon.com.au/

skype. gb.daemon

twitter. @modius

[James Buckingham]

Thanks Geoff for the quick reply.

Ouch nasty death :-)

If that approach was taken (and any advice on approach would be appreciated) how would I migrate the existing handpicked rules across?

Or you are saying I should overwrite the existing one?

I'm trying to identify what's different with the handpicked rule to the others, as it seems to be the only one doing it.

Thanks again,
James

[James Buckingham]

A bit more investigation work, it looks like this is going beyond Handpicked rules :-(.

In 6.1.1 I just now I've tried using one of our project's own "list selected" rules. I've picked some records and when I hit the next step on the wizard RHS menu I get the following error:-

There was a problem with that last request!

Please push "back" on your browser or go back home

Error Details

Message	Element OBJECTID is undefined in a CFML structure referenced as part of an expression.
Exception Type	Expression
Detail
Tag Context	C:\Inetpub\farcry\projects\website\webskin\ruleSelectedCaseStudy\update.cfm (line: 78)

C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 442) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 332)

C:\Inetpub\farcry\core\packages\rules\rules.cfc (line: 156)

C:\Inetpub\farcry\core\webskin\rules\editInPlace.cfm (line: 9) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 442) C:\Inetpub\farcry\core\packages\fourq\fourq.cfc (line: 332) C:\Inetpub\farcry\core\webtop\conjuror\invocation.cfm (line: 152)

Again when creating a new rule it's ignoring the selected objects, trying to edit the objects have disappeared.

The one thing these two have in common is they're both using an update.cfm and wizard custom tags to build the rules form. I've another in the project which holds just an execute.cfm and that's working fine.

Line 78 in the above example BTW is:-
<ft:object objectid="#stWizard.data[stobj.objectid].aObjects[i].objectid#" lfields="url" r_stFields="stFields" />

I'll need to do some more digging as to where the objectID its referring to has gone but thought I'd drop this in for now.

Cheers,
James

[Geoff Bowers]

You'd have to post the code for the update.cfm -- its unusual to have rules with UI that's so custom that you need to step away from the standard formtool edit handler... or rules that have wizards at all. What is the rule edit interface doing that needs a hand crafted wizard?

[James Buckingham]

Thanks again Geoff.

The lastest error is coming from the attached update.cfm.

Looking at the rule in 5.2.3 there is an extra step "Selected URL". It's giving the Editor the option to select which FURL should be used with the selected object ( i.e Case Studies ). I guess the idea is depending on the context different users would want to promote / display a different link on the page. I'm not 100% sure but it went in as part of the original project.

In terms of the Handpicked Rules the user has the ability to select objects and then on an extra wizard step pick from a list of templates how they want each individually displayed. So they can pick a global layout for the whole rule + individual templates for each selection.

[Geoff Bowers]

On Wednesday, October 19, 2011 12:36:05 AM UTC+11, James Buckingham wrote:

In terms of the Handpicked Rules the user has the ability to select objects and then on an extra wizard step pick from a list of templates how they want each individually displayed. So they can pick a global layout for the whole rule + individual templates for each selection.

Sounds like you may not have updated to the lastest ./plugins/farcrycms code base.  Make sure you are running on the latest tag build. 

https://farcry.jira.com/source/browse/CMS/tags/milestone-6-0-15

[Geoff Bowers]

On Wednesday, October 19, 2011 12:36:05 AM UTC+11, James Buckingham wrote:

Looking at the rule in 5.2.3 there is an extra step "Selected URL". It's giving the Editor the option to select which FURL should be used with the selected object ( i.e Case Studies ). I guess the idea is depending on the context different users would want to promote / display a different link on the page. I'm not 100% sure but it went in as part of the original project.

This sounds like a very bad idea.  The FU sub-system is designed to follow SEO best practice and enforces a single canonical URL. Even if multiple FUs exist, they're all 301 redirected to the principal FU. Furthermore, the rule should be using application.fapi.getLink() or skin:buildlink tag to build the most current version of any FU in the system. Allowing the user to choose an FU essentially goes against the principles of the underlying framework, and I'm not sure I can see any specific business benefit from having that configuration option.

Recommend ripping out the "select which FURL" option and programmatically building the correct FU at run time in the view.

[James Buckingham]

Funny you say that Geoff at close of business yesterday I was asking what we actually use them for. Nobody seems to know.

Given the problem we've currently got it out seems like the best approach with Case Studies, at least short-term.

That one is a minor though compared to the handpicked rules which we seem to rely on heavily. As I've had rightly pointed out we use these for things like "Grid" layouts - i.e a 3x2 table with handpicked teasers are placed in each cell.

From what you were original describing I don't think that's possible with individual content type selection rules.

The update.cfm issues are a good starting point for working out the problem, which I'll be doing today, but given there is an issue with the native rules themselves I'd appreciate any advice on how best to get these back up and running :-)

Thanks again for all your help
James

[James Buckingham]

Sorry just seen this after replying. I downloaded a copy of the CMS from the FarCry website at the start of the upgrade.

Doing a comparison with the one in the repository it looks like I'm running 6-0-15.

Cheers,
James

[Sean Coyne]

I tested this in a fresh p610 install with the latest farcrycms from SVN and I saw the same error with the handpicked rule.

I tried to track down the bug, but was unable to do so and ran out of time to continue trying.

That said, I would suggest you create a "grid" rule where you can select 6 items.  This would be a simple rule to create.  You could either use an array field and allow the user to select the items and use the sort order to layout the grid or you could create the six separate UUID fields.

Create a displayTeaserGridCell.cfm webskin and put the display code there for each custom type you allow the user to select.  This way the user doesn't have to choose a webskin.  

When creating your rule using either an ftType="array" or ftType="uuid" you would specify an ftJoin="" attribute that would be a comma separated list of all the content types you want to allow the user to select.

This would allow your users to select any objects they want and easily display them.

You wont need an update.cfm webskin.  Just let FarCry build the form for you.  This will vastly improve both the user experience and the maintainability of the code since you will only have 1 CFC to maintain for the rule (which will either be a single cfproperty tag or 6 depending on which way you go), and the displayTeaserWebskin.cfm for each content type.

If your content objects are fairly similar, you can also create a displayTeaserGridCell.cfm webskin in the "types" folder which will be used for any content type that doesn't have its own webskin.  You could then override for a couple custom types if necessary and have even less to maintain.

If I have some additional time soon, which is doubtful :(, I'll try to look at the handpicked rule again but you should be able to create more user friendly and simpler rules rather quickly to replicate this functionality.

[Blair McKenzie]

James, it sounds like you may have customised the handpicked rule. The fixes we worked on involved the edit handler in particular, so if you have a custom update.cfm you may need to remove it.

Blair

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

[James Buckingham]

@Sean - Thanks for the detailed reply and it sounds like a familiar story with trying to find the bug :-).

The "grid" was just one example of how they use it but as I said to Geoff these handpicks are used heavily by the Editors across the whole site. Creating fresh rules and expecting them to migrate everything across is probably going to be a lot of work and outside the project scope. The main purpose was to get FarCry up to version 6.1.1. with the minimum amount of change :-)

I'll keep it in mind though as I'm getting the impression from all this feedback that Handpicked Rules are becoming an old school way of doing things.

@Blair - Yeah you're right that we've over written the rule, back in the original installation of FarCry (version 5.2.3). If I revert back then I end up with the CMS error I mentioned in my first post and we lose our existing functionality. Reverting would also cause us the extra work I've just mentioned to Sean so I'm at a bit of a lose on how to approach this one. I need to have a think :-).

Cheers,
James

[Sean Coyne]

James,

Post the bug to the issue tracker for the farcrycms plugin.  I found the same issue in a fresh 6.1.2 install w/ the latest copy of the plugin.  You can create an instance of the rule, but then if you go back in to edit it, when you click save it throws the error.

You could build your own rule that works as the handpicked rule does.  If you use the same cfproperty tags you could even name it the same and your data would migrate over automatically.  However, what I would do is modify it so that instead of using an extended array and allowing the user to select a different webskin for each type, create a single common webskin for each type then write the rule to always use that webskin.  Then you can just let FarCry build the form for you (no need for a custom update.cfm) and just let the users add the items via an array picker.  There would be no second step.   My guess is that the bug is related to the extended array, but its just a guess at this point.

The code in the CFC would most likely be the same, you would remove the update.cfm and modify the execute.cfm to assume a single, common webskin name.

I think that might be your best bet unless someone at Daemon can find a fix for the bug.

[Geoff Bowers]

Off the top of my head, I'd say its likely we're not properly supporting "extended array tables" with the new dbgateway model in 6.1. Extended arrays should die in a fire. I think hand picked rule is just about the only core thing that references that "feature".  If that is the case, it may not have a simple fix.

If hand picked is critical in the short term, I'd recommend going with the latest milestone of 6.0.x (6.0.15). There's hardly any user oriented changes in the 6.1 release (relative to 6.0).  6.2 will see a lot of great new user enhancements, and the migration from 6.0->6.2 should be pretty simple.

Hope that helps,

[James Buckingham]

Hi group,

I've finally managed to work this one out.

The problem seems to be coming from this line in the CMS > Packages > Rules > ruleHandpicked.cfc.

<cfproperty ftSeq="2" ftFieldSet="Selected Objects" name="aObjects" type="array" ftJoin="dmEvent,dmFacts,dmFlash,dmFile,dmImage,dmInclude,dmLink,dmNews,dmHTML" arrayProps="webskin:string" ftLabel="Select Objects" />

When the BaseGateway is doing lookups through joining tables it now seems to rely on there being a _aObjectIDs suffix on the table name.

That's a change from our 5.2.3 copy because FarCry didn't used to care what the property was called (or is this maybe a bug in core if it's not actually meant to care?)

The steps I went through to fix this are:-

1) Remove the "aObjects" property above and replace it with one called "aObjectIDs". Deploy that through the webtop. Syntax I've got for this is:-

<cfproperty ftSeq="2" ftFieldSet="Selected Objects" name="aObjectIDs" type="array" arrayProps="webskin:string" ftLabel="Select Objects"
                ftJoin="dmEvent,dmFacts,dmFlash,dmFile,dmImage,dmInclude,dmLink,dmNews,dmHTML"  />

The methods in that rule ftEditAObjects and ftValidateAObjects also need to be renamed to ftEditAObjectIDs and ftValidateAObjectIDs or the formtool won't load into the page.

In my case, as I'm extending the Plugin's Handpicked Rule anyway, I've placed new methods in my project and just passed the request up to the plugin's original methods.

    <cffunction name="ftEditAObjectIDs" access="public" output="false" returntype="string" hint="This is going to called from ft:object and will always be passed 'typename,stobj,stMetadata,fieldname'.">
        <cfargument name="typename" required="true" type="string" hint="The name of the type that this field is part of.">
        <cfargument name="stObject" required="true" type="struct" hint="The object of the record that this field is part of.">
        <cfargument name="stMetadata" required="true" type="struct" hint="This is the metadata that is either setup as part of the type.cfc or overridden when calling ft:object by using the stMetadata argument.">
        <cfargument name="fieldname" required="true" type="string" hint="This is the name that will be used for the form field. It includes the prefix that will be used by ft:processform.">
        <cfargument name="stPackage" required="true" type="struct" hint="Contains the metadata for the all fields for the current typename.">
        <cfreturn ftEditAObjects(
            typename     = arguments.typename,
            stObject     = arguments.stObject,
            stMetadata     = arguments.stMetadata,
            fieldname     = arguments.fieldname,
            stPackage     = arguments.stPackage
        ) />
    </cffunction>

2) I then run a migration script that copies the records from the old aObjects table to the new aObjectIDs one. Happy to drop that in here as well if people need.

Handpicked rule, and our CaseStudy that had the same aObject name, are now fixed!

-----

So I guess in terms of a fix for future releases you'd be looking to either changing that property name on the CMS rule or the BaseGateway needs something in there to look for a suffix of the properties name instead.

Hope that helps someone else & I'll drop reference to this in the bug ticket as well.

Cheers,
James

[James Buckingham]

P.S. The following also allowed me to remove the update.cfm in each of these types :-D

[Jeff Coughlin]

I could be wrong, but that sounds like a bug.  It shouldn't be requiring you to name it a very specific way like that (forcing you to use the string "IDs" in your array name reference).

@Geoff, please don't kill extended arrays.  It's an extremely useful feature if one knows how to use it properly (we use it when the time calls for it - especially on larger projects).  FarCry's ORM is great, but it lacks a lot of advanced features that more robust ORMs have.  However, extended arrays at least give us a little extra usage for adding those extra fields when needed (and trust me, for more complex projects it's sometimes needed).  I know we need to pull certain features and rethink others every now and then, and maybe extended arrays could use a little more love.  But they work, and they work well.  Lets please not make FarCry's ORM take a step backwards with this one.

Wishlist:  :)

Personally I'd like to see extended arrays get more attention and better recognition from the CMS as truer objects.  I'd also love to see the ORM have better distinction with many-to-one, one-to-many, and many-to-many (yes, FarCry has these... sort-of, but it could be much better defined).  Finally, I'd also like to see configuration objects (packages.forms) act more like FarCry objects (allowing things like arrays).  Okay, all a wishlist I know.  But it doesn't hurt to ask.  I'm not against the idea of migrating FarCry to use CF9's ORM either (don't throw tomatoes just yet.  It's just a thought :).

--

Jeff Coughlin

Web Application Developer

je...@jeffcoughlin.com

http://jeffcoughlin.com/blog

[Blair McKenzie]

That does sound like a bug. I haven't seen that problem with arrays, have you Jeff?

Extended arrays are going to stick around. In very, very rare situations they the only solution. In 6.1 I was able to change array updates to use the same functions as primary objects.

I believe configs have been able to support arrays as of one of the recent 6.0 releases, thanks to improvements in the library picker. We haven't tested it extensively though.

Blair

[Phillip R]

Hi Guys,

Just in case anyone else has been struggling with the Handpicked rule issue I though I'd suggest that the solutions above (which I've been using) are not necessary at all. The issue that causes the 

	[objectid] is part of this table's primary key and must be included in stProperties

is actually the /packages/types/ruleHandpicked_aObjects.cfc which extends farcry.core.packages.types.arrayTable. From what I can see it isn't required as the webskin list is created in the ftEditAObjects with a getWebskins call.

The ruleHandpicked_aObjects.cfc in the types folder seems to make an objectid required on saving, which it doesn't have. Ergo the error. My suggestion is to remove the ruleHandpicked_aObjects.cfc file completely and do a restart of the app and you should be good to go.

As a side note, if you have a rule in place and you add a new item to it, the webskins all revert to the default (or top of the list) webskin. 

If you replace <cfset thiswebskin = "" /> at around line 79 of ruleHandpicked.cfc with:

<cftry>

<cfquery datasource="#application.dsn#" name="wk">

SELECT webskin

from ruleHandpicked_aObjects

WHERE parentid='#stObject.objectid#' AND seq=#i#

</cfquery>

<cfset thiswebskin=wk.webskin>

<cfcatch><cfset thiswebskin = "" /></cfcatch>

</cftry>

The existing (saved) webskins will be retained (except for any just added).

Phillip

[Geoff Bowers]

Thanks for that Phil, we'll get the code base updated shortly.

GB

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

---
You received this message because you are subscribed to the Google Groups "farcry-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to farcry-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.