This project is read-only.

custom module not showing in list of available parts

Topics: Writing modules
Nov 28, 2011 at 10:47 PM

I've create a new custom part, which I've also enabled in Orchard > Modules > Features. Orchard version 1.3.9. When I try to make if visible in Orchard (following guidelines here:, it doesn't appear in the list of available parts to add (e.g., to a page). What am I missing or what is the recommended way to add a part to a page or otherwise get it to be available for use in Orchard? Thanks

Nov 28, 2011 at 10:51 PM

It just has to be attachable.

Nov 28, 2011 at 10:54 PM

Right, I've added this code in Migrations.cs just before return 1;


typeof(UserLocatorInfo).Name, cfg => cfg.Attachable());

 Is that what you  mean?




Nov 28, 2011 at 10:57 PM

Yes. That should be enough. If it's not, well, several things to check: is your module actually enabled? Did your migration actually run? Isn't the part already attached to the type you're looking at?

Nov 28, 2011 at 11:04 PM

The module is enabled. The migration created the table (no records). Not sure of the meaning of your third question, but the new content part is nowhere to be found on any of the Content tabs/screens.

Nov 28, 2011 at 11:07 PM

And that code was in the same migration step that created the table?

Nov 28, 2011 at 11:11 PM

I believe this is what you mean... the code is like so:

using System;
using System.Collections.Generic;
using System.Data;
using Orchard.ContentManagement.Drivers;
using Orchard.ContentManagement.MetaData;
using Orchard.ContentManagement.MetaData.Builders;
using Orchard.Core.Contents.Extensions;
using Orchard.Data.Migration;
using CallRsvpSvc.Models;

namespace CallRsvpSvc {
    public class Migrations : DataMigrationImpl {

        public int Create() {
			// Creating table UserLocatorInfoRecord
			SchemaBuilder.CreateTable("UserLocatorInfoRecord", table => table
				.Column("FirstName", DbType.String)
				.Column("LastName", DbType.String)
				.Column("RsvpCode", DbType.String)

            ContentDefinitionManager.AlterPartDefinition(typeof(UserLocatorInfo).Name, cfg => cfg.Attachable());

            return 1;
Nov 28, 2011 at 11:15 PM

OK, I'd guess we're looking at the wrong place here and that there is a problem with the part itself, not with the migration.

Nov 28, 2011 at 11:25 PM

Hmmm... I see, said the blind man... well, I guess I'll look at a part I wrote that *is* working that shows on the main settings page. Any other thoughts?

Nov 28, 2011 at 11:30 PM

Not really. I don't *think* the problem is in the code you've shown, so look at the code you haven't. Ah, you can also look at the Settings_ContentPartDefinitionRecord to see if your part's settings specify attachable.

Nov 28, 2011 at 11:35 PM

ok, I'll check out the Settings_ContentPartDefinitionRecord code. Thanks for your help.

Nov 28, 2011 at 11:37 PM

Database table, not code.

Nov 28, 2011 at 11:51 PM

So there is no corresponding record for my part in the Settings_ContentPartDefinitionRecord table...  

-- would adding it manually remedy the situation for now?

-- what would have caused that to be skipped?

Nov 28, 2011 at 11:54 PM

Did you add the Attachable to your migration after you already installed the module? You'd need it in an UpdateFrom1() so you can do a further update, or just delete your database and start again.

Nov 29, 2011 at 12:12 AM

Yeas, dont'add it manually, do what Pete said.

Nov 29, 2011 at 1:11 AM

ok makes sense -- yes, I think that's what happened -- added attachable after the initial install/enable. Rather than deleting the entire DB, I was thinking I'd disable the module and drop the part table, but maybe there are too many other DB updates to back out? I don't really want to drop the entire DB due to other unrelated updates if I can avoid it.

Nov 29, 2011 at 1:25 AM

When you add something to a migration, the standard way of doing it is to add a UpdateFromX method. That's pretty much the whole point of migrations really ;)

Nov 29, 2011 at 1:38 AM

There's a migrations table that stores the last executed migration number; so even if you drop a table the system will still think you're on version x and won't know to run Create again. You can manually alter the version numbers in the migrations table, on the occasions you need to rerun or just test stuff and don't want to regenerate the whole DB.