How to delete module commands in published contents?

Hi !

I face the same problem.Whatever commands are there in my command list, appear as it on the published pages right above the content.

Also, If i try to edit the created pages, I get the following error:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'blog_node_form' was given in /var/www/drupal/includes/form.inc on line 218.

and hence, I cant even remove the commands manually.

Any Help ??

Do you have a space between the commands and the values? (like type: and page)

As a feature request, I'd suggest that both with and without space be supported.
As these parameters are theoretically able to be entered by misc users, the current syntax that requires a space is hard to document and remember.
I don't think there's any drawback to allowing this?

@dman: I don't see any drawback myself, but please open a new issue for that, or let's wait for zappa's or seige's response, regarding the source of their problem.

I added the space after every : and the problem is resolved.

However, my other problem still remains unresolved.

When I check the content section, I see a new post but the type attribute is somehow not set to "page".Its just null.
The status of the page is unpublished even though in my command list , I have "status: 1"

My complete command list looks like this :
-------------
type: page

status: 1

format: 3
-------------

If I try to edit the post, I get the following error message :

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'blog_node_form' was given in /var/www/drupal/includes/form.inc on line 218.

Any help on this as well would be awesome.
Thanks a lot again for all the info

It seems that those commands are not making it through the system - although they are now being recognized enough to be removed.

The default fallback page type is 'blog' which becomes an invalid option if blog.module is not enabled. (this error should be caught in the code - another feature request I guess)

Posts not being a page and not being published are all parts of the same symptoms.

Probably still something to do with the syntax that's coming in. Like your client sending HTML-email?

I am sorry but I could'nt get the gist of your message.
Do you think there is a problem with the message being sent by the email client i am using in conjunction with mailHandler.
I have configured GMAIL pop3 with it.

Not very sure of how to resolve the errors !!

The reason i am trying to get this to work is because I want to transport a website to drupal.The import_html module doesnt work very well. I want to write a script that will email all my pages to an email account which is registered with MailHandler and hence, my pages are automatically created.

That's an interesting approach.
I'm just trying to identify the stages in the process that may help debug and track down what can be done. I don't have your full answer.
I think it's in the parsing of commands, which is quite strict about what it expects. So knowing the formatting that's happening to the input helps.

If you just need a one-off fix, you can use the default commands to ensure the type is page and the published is true. Easier than adding commands to each page.

.dan.

@seige: please make sure you have a content type called "page" (that you didn't erase it by mistake).
Also - dman's remark about the HTML might be true as well, although I'd expect to see the commands in the node's body, in case they are not parsed by mailhandler.

To start debugging, I suggest:
a. try to use another content type
b. try to use a single command in the *default commands section* (which will be the "type" command with a valid content type)

That's an interesting approach.
I'm just trying to identify the stages in the process that may help debug and track down what can be done. I don't have your full answer.
I think it's in the parsing of commands, which is quite strict about what it expects. So knowing the formatting that's happening to the input helps.

If you just need a one-off fix, you can use the default commands to ensure the type is page and the published is true. Easier than adding commands to each page.

.dan.

I tried removing the commands entirely as well as just keeping one command i.e. type: page

However, i get the same results. The imported node doesnt have a type and its status is "not published". On my attempt to edit it, i get the error message i mentioned earlier.

This leads me to believe that the dafault set of commands are not working properly.

Any more suggestions ? This is getting frustrating.

Any help on how to make mailHandler create "page" nodes ?
This is one of the most basic requirements of the module. I wonder how other people have managed to get around this ?

Allright, I read the comments again and finally am able to proceed a little further.

I saw that dman's comment says enabling of blog module which i had not done.

So i enable the module and try it again. This time my mail gets transformed into a node with type "blog entry" and i can edit it too.
So atleast whatever content i email, a node is created for that which is editable.

Now, I dont want to create a "blog entry" node. I want a page node to be created of every page i email. I have type: page in my commands list. Any further suggestions on how to get a node of type "page".

Another discovery:

Disable TINYMCE else your commands wont work.

@seige: thanks for sharing this sad discovery! I wonder what makes TinyMCE to break mailhandler's operation....

I don't think it's TinyMCE's fault.

If you use any kind of WYSIWYG editor, you usually enable FullHTML filter. That will insert some HTML line break (<br>) or paragraph (<p>) tags into what seems like plain text. That will prevent commands from being interpreted by mailhandler module. So it's better to use a plain text editor for inserting module commands.

Frank