Is there any plan to add a muraCms importer?
Most importers were contributed by someone the first time they needed to import from that system. We would welcome additional importers if you would like to create one.
Each importer is a single CFC that is located in the /modules/contentbox/model/importers/ directory. You can look at an existing one to see how it works.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Here is some motivation. $100 amazon gift card for it.
Go!!
I’m trying to create a mura importer. However it seems that mura does not have the concept of blog. All content is a page. So what to do now? I should consider all page of muracms as an entry in contentbox?
So there is nothing to distinguish a page from an entry in Mura?
To be more clear, muraCms is more a content management system. So it creates a lot of pages that could be intended as blog posts.
Importing those pages into coldbox we should choose if we want consider those pages as blog posts or as pages. There is not a programmatically way to discriminate between post or page in mura.
So what to do now?
Yeah I think this would not work as a normal importer, unless they where flagged as separate content type and a module could be added to the dash board to mark which is which. Unless something can identify the content, that would be the only solution.
Actually I was just looking at the DB schema on GitHub the field Type can identify it, but not sure as there is a default and page. Could this be a way to tell?
A solution could be adding an input field on import page called blogtree, show this when user select mura importer on selectbox and use the value inserted on it to then query all mura pages that are children of that value and import them as blog entry. The other pages would be imported as normal page.
@Andrew valid Type of content in mura are Page,Link,File,Folder,Calendar,Gallery.
@Brad From what I know about mura I say yes.
Here is a screenshot from my local install: http://awesomescreenshot.com/0a82l8xcbc
Blog is a simple page with sub-pages
Ok, then here is what I would do.
As this is an import that is normally at the very beginning, would it not be easy just to import them all as pages. This would allow them to maintain the old way, as well as going forward they could have each migrated individually to a CB Entry.
As they are used to pages, I wold assume pages should be the way it is imported to maintain consistency.
I think the ideal solution would be to present the user with a drop down of pages and have them choose which one (if any) was the parent page for the blog.
The main issue with this is that the Blog importer does not allow for individual importers to specify custom form fields— let alone, additional pages since this drop down could only be created AFTER the data source name, etc was collected. Minimally, we could forgo the drop down and just require the user to specify the slug on the start page.
Either way, this would require enhancements to be made to the ContentBox core. How do people feel about these possible enhancements?
- Allow each custom importer to declare custom form fields to be collected via a variable in the “this” scope or an array returned from init, or returned by a method named by convention. These fields would be dynamically included on the screen under the stock fields and passed to the importer in a collection. See how Railo Cache drivers work-- they can declare fields programmatically. (Example below)
- Allow importers to define multi-step wizards. The steps can be declared in a “this” variable, or via methods named by convention. step1_fields(), step1(), step2(), step2_fields(), execute() etc. All data from steps would be passed along or stored in flash ram for the duration of the import “wizard”. This would allow the importers to collect info from the database, and then have users select which entries to import, etc.
These are just ideas off the top of my head. I haven’t put in any tickets-- just wanted to get feedback. Here’s example of how Railo allows Cache drivers to declare dynamic form fields. Railo builds all the HTML for you:
<cfset fields=array(
field( displayName=“Couchbase Server Hosts”,
name=“hosts”,
defaultValue=“localhost:8091”,
required=true,
description=“Couchbase server host and port. Ex: localhost:8091
Put each server and port on a new line.”,
type=“textarea”
),
field( displayName=“Couchbase vBucket Name”,
name=“bucketName”,
defaultValue=“default”,
required=true,
description=“Couchbase vBucket to connect to.”,
type=“text”
),
field( displayName=“Bucket password”,
name=“password”,
defaultValue="",
required=false,
description=“Password for this bucket. Probalby blank if using ““default”” bucket.”,
type=“password”
)
)>
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Francesco,
What about using the slug in the URL. If it contains “blog”, then imported as an entry?
If not, since they don’t distinguish, maybe they can be imported as pages.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Luis, I am thinking the slug name might not be always blog.
Brad, I like #2.
Why not add a single input field to choose the slug?
I know I am coming late to the party, but why not make whatever slug name the importer is looking for dynamic?
George, if the slug is easy to get at, yes that would work and I mean one could do a lookup in the DB and know that is the slug for blog page. I am guessing as I only had a quick look, being a page it could be named anything.