Create Article Resource via snippet

We’re successfully creating a new resource from user input. This is done via a front end FormIt form with a hook. This uses the influencerPageGenerator as seen here: https://forums.modx.com/thread/88270/create-a-new-modx-resource-with-the-api

All works well, only the pages.resources we create however need to be ‘Articles’ as the client is using the Articles plugin to create this particular kind of page. So the ‘$parent’ resource ID is actually an Article container resource.

So rather than the resource appearing in the regular resource tree, it needs to be added to the Articles resource list. We’ve looked through the various files in the Articles plugin but are not 100% sure about how to go about this.

Would anybody be able to point us in the right direction?

1 Like

Did you set the class_key to Article for the new created resources?

1 Like

What you want should happen automatically as long as the class_key is set to Article and the parent field is set to the ID of the Articles Container.

1 Like

Thanks for the replies. We’ve amended the code to this:

$doc = $modx->newObject('modDocument');
  $doc->set('class_key','Article');
  $doc->set('parent',$parent);
  $doc->set('pagetitle',$pagetitle);

etc

but it creates a 500 error. Are we setting the class-key incorrectly?

1 Like

You may need to first make sure the Articles service is loaded.

This may also help:

$doc = $modx->newObject('Article');
$doc->set('class_key', 'Article');
$doc->set('parent', $parent);
$doc->set('pagetitle', $pagetitle);

If that doesn’t resolve it, look at your PHP error log for the reason behind the 500 error. That would be massively helpful identifying what is going wrong.

1 Like

Mark may well be right, but I was going to suggest this:

$doc = $modx->newObject('modResource');
1 Like

Thanks Mark & Bob,

Turns out the 500 error was just our stupidity. However, Bob’s suggestion of
$doc = $modx->newObject(‘modResource’);
$doc->set(‘class_key’, ‘Article’);
now works and creates the page in Articles with the correct parent.
Much appreciated.

1 Like

I finally found the time to look at how the process I suggested affects the database. Unless you set them explicitly, the createdon, createdby, alias, and publishedon (if you set published to 1) fields are not set. The publish_default and automatic_alias System Settings are ignored, as are the other defaults like richtext, hidemenu, searchable, etc.

In addition, the normal events, OnBeforeDocFormSave and OnDocFormSave are not fired, so any plugins attached to those events will not execute.

A much better method is to just use the resource/create processor:

/* Article Creation Code */
$articleFields = array(
    /* set this to the ID of an Articles Container */
    'parent' => 12, /* Required */

    /* set this to the ID of the Article Template
       (*not* the Articles container template) */
    'template' => 122, /* Required */
    
    'pagetitle' => 'Blog5', /* Required */
    'class_key' => 'Article', /* Required */
    'content' => '<h3>Blog 5</h3>',  /* Optional */
);

$modx->runProcessor('resource/create', $articleFields);

The other fields will be set automatically, though you’re free to set them yourself if you don’t want the defaults or have other fields to set (e.g., introtext or description).

The System Setting defaults (including automatic_alias) will be honored.

And if you set published to 1, the publishedon and publishedby fields will be set.

You may also want to set the createdby and publishedby fields to the ID of a user other than the admin.

The events will be fired and any relevant plugins will execute.

Note that the process may throw a few harmless warning and info messages, but normally, you won’t see them.

1 Like

Thanks Bob.
We have tested the code, replacing the previous. It works!

One thing which we are having problems with:
the ‘template’ => is set to the correct template (the actual ‘article’ template, not the articles container). ‘published’ => is set to 0. The page appears in the correct article list, unpublished. Brilliant.

However, when we publish, a link is added in the Wayfinder to the new page at the same level as the parent container. The Wayfinder is actually then closing the rowTpl tags around the new page before moving on to the next item - the next item is now actually the parent of the new page! This totally screws up the menu.

I’ve looked through the DB to see if a can see obvious differences between pages published correctly in the manager and those created by our script, but there is nothing obvious. The parent has been set correctly.

The only difference I notice is in the article page comments tab. On the page created by the snippet there’s a ‘quip.thread_err_nf’ message’, but I guess that’s a red herring?

That means that it can’t find the quip thread ID for the message. I’m not sure what that means. I don’t think it’s related, but I could be wrong. Looking in the DB, the Article objects look exactly like the modResource objects and are in the same table.

In your code, did you set the menutitle field to be what you want to show in the Wayfinder menu (I think it defaults to the pagetitle).

Make sure you set the parent field to the ID of the articles container. This is the most likely issue. If you don’t set the parent, you get a parent of 0, which puts the new article at the root of the tree.

Sorry guys, it was a mistake in the hidemenu field. Now set to

‘hidemenu’ => ‘1’

No problems. Thanks Bob.

I’m glad you got it sorted. :slight_smile:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.