Content type key saved as lowercase for Workflows activity

Topics: Core, Troubleshooting
Developer
Aug 22, 2013 at 11:41 AM
This is very interesting: when I add a workflow with the content created event with the latest source, the row in the Orchard_Workflows_ActivityRecord table contains {"ContentTypes":"Whatever"}. Notice "ContentTypes".

When doing the same with another instance of mine that supposedly has the same version of the source {"contenttypes":"Whatever"} is saved. Notice the lowercase "contenttypes".

Why is it saved with lowercase now? Interestingly enough, although the PascalCased version is referenced in the code it works nevertheless (a few versions before it wasn't working).

Anybody with an idea?
Developer
Aug 22, 2013 at 1:19 PM
Edited Aug 22, 2013 at 1:19 PM
The issue is that somehow on the problematic instance not Orchard.Workflows.Forms.ContentForms was used but Orchard.Core.Contents.Rules.ContentForms because they have the same name... The two forms are identical except that the latter one contains the field name in all lowercase. Both of the forms are getting registered on both instances (with Rules switched off), however on the problematic one the the one in Core gets registered last (and thus, wins).
Developer
Aug 22, 2013 at 8:11 PM
Edited Aug 22, 2013 at 8:14 PM
Hmm, it doesn't have to do with the enabled features (the other instance with the same ones enabled works), neither whether the site is run through IIS Express with Ctrl + F5 or as a web application set up with IIS Manager.
Developer
Aug 22, 2013 at 8:34 PM
Adding "Contents" to the dependencies of Workflows enforces the registration order that's the case by default for the working Orchard instances, thus the new form "wins". I'm curious though why this is not the case by default.
Developer
Aug 22, 2013 at 11:13 PM
I found the source of the issue: the Watcher module, when added to the solution (even if disabled and never enabled!) was causing this. Why? Because it has a dependency declared on Orchard.Workflows in the Module.txt.

Now this the problem can be reproduced by adding "Orchard.Workflows, " to the beginning of the dependencies of other modules too, e.g. Lucene.
Developer
Aug 23, 2013 at 4:52 AM
And the moral of the story is - nothing helps better than a good ol' discussion with yourself!;)
Weird issue though...
Developer
Aug 23, 2013 at 9:37 AM
Oh yeah :-). This is indeed weird and can imply further issues where code depends on Core dependencies being registered first.
Developer
Aug 27, 2013 at 12:24 PM