Fieldtype Import Pages (Fieldtype to store multiple pages to a conditional/predefined parent.)

[Martijn Geerts]

FieldtypeMultipages

I wish there was a Fieldtype that can store multiple pages in a predefined/conditional parent. The Fieldtype doesn't need to save data under the current Page. I think it has to return (after $page save), true when all pages are stored or a Pagearray with page(s) that failed to store. (or ids from success pages and ids from not saved pages )

What the Fieldtype need to know from the Inputfield.

From Inputfield (getConfigInputfields)

• Parent ($page object)
  • empty ( $page is assumed as parent )
  • selector ( use a selector to determen the parent )
  • id ( Id of the parent )
  • conditional (conditional the the template of the to be saved page)
    • (parent from to the to-be-saved $page->template. example input:
      • basic-page | 1047 ($Page with tpl basic-page will be stored in parent with ID 1047)
      • gallery | /parent=$page/ *($page with tpl gallery will be saved under the current page)

Required from Inputfield (@return Pagearray and a $parent) - Pagearray containing pages to be saved under Parent. - A parent ($pageobject) or conditional, so field type could figure out where to store

The Inputfield should collect all Pages in a Pagearray and give it back to the Fieldtype. The fieldtype should then handle the saving of all pages in the parent.

---

It could be used for:

Inputfields like:

• Table.
• Store RSS/Atom entries to pages.
• What ever you want to be saved in a specified parent.

---

I Post it here, cause I don't have the skills to create such fieldtype (relyable) & it should be that reliable that developers could build inputfields for this.

--- Changed Title of the post

[Soma]

I've read this slowly several times now and couldn't understand what it's about really. Can you explain differently what this would do?

[Martijn Geerts]

Tonight when i'm behind the laptop I will eplain an input field that can use this inputtype. Think explaining the inputfield explain the fieldtype to.

[MatthewSchenker]

Greetings,

If I understand this correcrly, building pages from the API makes this poasible without a new field type. Generally, when I have people adding pages using front-end forms via the API, I have specified places for creating pages they need. For example, I'm working on a project now where I created an "admin options" page that has the following links:

- Create new show

- Create new gallery

Choosing one of those options brings them to the page-creation form, which is coded to set the new page as a child of "Shows" or "Galleries" (depending on their choice).

You could do the same thing by having a "Create New..." select box containing the same choices (show, gallery), then use that choice as the parent when you actually create the page.

Of course, that's if you do this from the API.

If you're doing this from the admin back-end, where would you place it? The new-page process starts from the page tree, so how would you define where it resides?

Thanks,

Matthew

[Martijn Geerts]

Hi Matthew, Soma & others

Sorry to be that unclear and a half day to late with this post.

I gonna try to explain the Fieldtype again, I was not clear enough.

( Explaining things is always difficult and even more when it's not in your native language )

I gave the fieldtype an other name: Fieldtype Import Pages. As it describes better what it should do.

---

@MatthewSchenker, most things can handled easily from api. But the context (where to handle data) is very important. If you give an editor a page to edit*** and they can handle all the data there, then there's no confusion.

In MODX evolution galleries are created from the front-end of the website not the back-end. As a result: Customers calling that they can't edit galleries, you explain where to do it and a year later, the same customer is calling again with the same question.

*** example: /processwire/page/edit/?id=1047

---------------------------------------------------------------------------------------------------

Fieldtype Import Pages (Handeling Page imports)

The settings for inputfields using this fieldtype make things more clear I hope:

---

What should the Fieldtype do?

• import pages to a parent. (handeling page imports)

What data should be saved to the current $page?

• No data, it should create pages under a parent page.

What a "Fieldtype Import Pages" Fieldtype needs from it Inputfield:

• page array (pages to store) and a parent. 

What is the required output ( $page->name_of_the_field ) of the Inputfield using this Fieldtype:

• nothing, ( the Imported pages are the things you querie from template/api level )

What output is possible for a Inputfield ( $page->name_of_the_field ) using this Fieldtype:

• whatever the developer wants to output. ( depending on the saved pages.)

---

 

An Inputfield example:

 

Inputfield querying the latests tweets containing the hash tag #processwire and creating a list of it. 

In the inputfield select the tweets you want to import to a parent.

 

On saveReady*** , create a Pagearray of tweet pages. Then the Fieldtype kicks in and saves the tweets in the parent.

 

*** (or what ever state it is possible to create a pagearray before the Fieldtype kicks in )

 

---

 

Other Inputfield example

 

An inputfield using Wanze & Kongondo'z handsonetable creates a Pagearray and the Fieldtype wil store the pages.