How do I create an altered admin interface for creating / editing fields?

[jordanlev]

Hi,

I am attempting to create a process module that is basically an admin interface for configuring other fields and templates. (I am trying to automate the setup and management of flexible editable "areas", as discussed here: https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/ ).

I've got a lot of it figured out, but need some help with the "configure fields" section. In essence, what I'm trying to achieve is to have a separate page in the admin for managing some fields. So I want to use all the built-in functionality that exists on the normal Setup > Fields admin form, but include it in my own separate admin page. I have the process module set up and I know how to respond to certain url, but once a user is at my url how can I show them that "fields" form for a particular field? (Assuming I have the field id).

Also, I also want to do something tricky when I display that form: instead of the usual "name" field, I want to show the user a different textbox field (which I'm calling "handle")... the user enters a "handle" into that field (which I just made up myself... it's not part of processwire) and then on the back-end when I process the form submission I will take what the user entered for the "handle" and prefix it with another string and use that concatenated value as the field "name". So I want to hide the "name" field, add my own new field in its place, then programmatically generate the "name" myself *before* the form is validated and saved by processwire.

Any thoughts on how to achieve this? Thanks!

   -Jordan

[Soma]

So you're saying the user will create new pw fields for every new input he want to enter on a page? I don't think that's a valid approach.

[jordanlev]

No, not a new input per page -- rather, a new set of fields per template. (The same exact thing one would do when creating a new template themselves... set up some fields and add the fields to the template... but I want to automate the specific settings of all those because there are so many things that need to be configured in just the right way in order for things to work the way I want).

BTW, If you think that's not a good idea, that's fair, but could you at least explain your reasoning behind it? As a newbie to processwire, understanding the rationale for different approaches will help me learn a lot more than just getting a "yes" or "no".

Thanks!

[Soma]

PW template and fields system isn't meant to be used in such a way. It won't scale as for each field it will create a new table in db. I'm not sure the exact reason for this but looks like you try to bend pw too much in a way it's not meant to be used. If youre for a site builder system you might consider cms system that is designed for it. My recommendations are the one in the thread you linked too so no need to repeat here.

[jordanlev]

Thanks for your input, Soma -- I will take it under advisement. However, I still would like to build what I'm trying to build so I can see for myself if it's feasible.

I think what I'm trying to build is hard to explain in words (especially if you've never used a system that is block-based, like Concrete5 -- where I am drawing my inspiration from), but once it exists as an actual module you can interact with it will become a lot clearer.

All I am doing is creating a few extra templates with some fields for each one. Are you telling me that ProcessWire is not capable of having 6-12 additional templates, each of which has 1-6 fields in them? I would find that hard to believe since everything I've seen of ProcessWire indicates that it is perfectly capable of having many templates in 1 website and of course every template has slightly different fields in it. I thought the whole purpose of ProcessWire was to be able to have any fields you wanted in each template, instead of assuming you just have a "title" and a "body" like in wordpress?

[mr-fan]

i know the c5 structure (and i can remember you from the forum there - it's nice to see you here) and worked with a similar CMS that use modules as sections/blocks on a page.....and i know all the benefits!

Done some testsites, one rebuilding from the used CMS to PW and on the run one new PW site from the scratch.....and i don't miss this blockbased sheme anymore.

From the start i missed the easy things that possible with blocks/sections -> add a form there -> add a galerie here -> drag and drop the blocks.....but now i know with PW it is much more to think about the project first and then create it like it should be, than building fast on the fly in the CMS system.

I made for me an overview of the content-blocks- that i need to be used in a flexible way on some/every/single pages and thought about the options in PW......didn't found a usecase where i don't get a solution.

Only drawback is that a enduser couldn't expand the website like he wants (For e.g. put a new little form here, add a new gallerysection here, add a poll on this page).

But this stuff should be worked out previous the client needs such things....since he and you don't give the client the power to mess up his site.

I liked the way to work with contentblocks with different types - but i like the other way to create all that is needed and expand it if it's claimed, too!

just some thoughts on the block thingi

kind regards mr-fan (did like the idea/way of Concrete5, too but it's a resourcehungry, slow on sharedhosts, hard to translate beast )

[mr-fan]

Some "Mindgames"

Go further i could build some blocks to expand a page with PW, too.

Build a pagestructure like this one

- blocks

  - special content 1

  - special content 2

 ...

Just add a new tab on the basic-page template call it "blocks" and add a pagefield with pageselect or just checkboxes from the parent "blocks" and create the output with some if's how the content have to be if some special content is loaded.....

Ready to go flexible blocks for the client but exactly embedded in the content where needed.

Not really flexible since all is preset - but expandable if client need it.

[jordanlev]

Hi @mr-fan,

Thank you for your response. Can you please explain more about how you were able to build your sites without the flexibility of C5's blocks and areas system?

To me, the lack of such a system in ProcessWire is what holds it back from being able to serve as a good CMS for the kinds of sites I build (mostly marketing/informational sites with very custom designs). I understand that if the site you are building has a rigid data structure (almost like a database, like the "Skyscrapers" example site that ProcessWire has), then the limitation of having to pre-define the fields per template is best... but for so many of the sites I build, it would be very difficult to restrict our clients in that way. When we build wordpress sites (which we never choose on our own, but sometimes clients request it), we use the Advanced Custom Fields plugin to approximate some of the custom field aspects of ProcessWire, but what happens is we wind up creating a TON of different templates just to accommodate the different design options our clients might want. We have really found that a few custom blocks in Concrete5 go a long way to giving our clients the flexibility they need without allowing them to mess up the design too bad (this is why I have created the "Designer Content" addons in C5 -- to make it really easy to set up these custom content interfaces in a way that guides clients to enter just what they need and keep our design markup working well).

I see that a lot of people here on the ProcessWire forums like to use "Hanna Codes" in the CKEditor to achieve this kind of flexibility, and I think that works okay for some people if they are technically inclined. But in my experience, things like that are a terrible user interface for most non-technical people and it causes a lot of support headaches for us.

If you are making ProcessWire work for your needs, though, I really am very interested in hearing more details.

As for the implementation of a block system in ProcessWire, it actually is doable now with the new "PageTable" field type that is included in PW 2.5 (see the forum thread I linked to in my original post for details). The only problem with it is it requires a LOT of setup to make the fields and templates work in the right way. So I am trying to build an admin interface that provides an easy user interface for automatically managing all of the settings. It doesn't add any new functionality to ProcessWire itself -- it is just a nice front-end to existing features of the ProcessWire core system.

I am going to keep working on this, because I think once it is done people will be able to see how useful it is (and how it actually fits into the ProcessWire system quite nicely -- because it's just fields and templates, like everything else in the system). I wish I could get more technical help on how exactly to interact with the admin interface, but perhaps my question is too hard to answer in a forum and I just need to keep trying myself to make it work. We'll see how it goes

[jordanlev]

@Soma, I just discovered the Repeater field. You may be interested to know that this field does something similar to what I'm trying to do -- it creates new templates and fields and hidden pages. Since the Repeater is a core PW module, it seems to me that using this technique is not actually bending PW in a way it's not meant to be used. On the contrary, I think this is actually using PW in the exact way it is meant to be used -- where everything is a page, template or field (kind of like records, tables, and fields of a database). I agree that this abstraction can be taken too far (basically building a database on top of a database on top of a database, etc.)... but since I am just leveraging the existing PageTable field type I am not actually building an additional layer on anything.

And I think I've figured out how to solve my original question (or at least I am on the right track)...

$form = $this->modules->get('ProcessField')->buildEditForm();

//Now, I can override specific fields or page attributes of the form, for example...
$form->attr('action', 'add'); //overwrite form action

Neat!

[Soma]

I was in the assumption from your description that users = "editor" create new fields on the fly for every page. While this may possible it won't scale as it would end in too much custom fields when you have a site with hundreds or thousands pages each built that way. If for only used for a couple pages this could work fine, but don't see anything new that wouldn't be possible already with repeater or pagetable fields.

I'm using repeater since almost 3 years now, so I think I know what it does . But it doesn't scale well and Ryan is and was originally very sceptic about this sort of thing in PW. Currently there's a new field PageTable that works in a similar was (pages) but is slightly more efficient and flexible built. But still, as forseen, those fields often get misused in some way.

The PageTable currently is the most close mini system for building blocks and it works great. It may be of interest for you that MadeMyDay expanded the field a little with his: http://modules.processwire.com/modules/fieldtype-page-table-extended/ 

[mr-fan]

May you have missed this one - it's great extension to PageTable and fits different contenttypes even with rendering in the backend for easy editing by the client....

https://processwire.com/talk/topic/7459-module-pagetableextended/

and you are right i've mostly well structured websites, or simple i love to structure them for the clients needs. (i've mostly nontech users that have to search in word to get the text bold - they love that i preset everything in a very easy way for them)

If different layouts or blocks needed - i would think about the amounth and the usecases of them and use some PW features that i read about to get this work:

First use normal pages with all the fields that needed but only show "users choice" of the fieldsets:

https://processwire.com/talk/topic/4323-field-dependencies/

(Show contentblocks/wysiwygs/inputfields only if for eg. a checkbox is true [ ]two collums [ ] tree collums or maybe [ ] imagegallery)

pro easy to setup and to maintain for the client - con no sorting of the contentblocks again a given structure...so not best solution

Second shot would be a pagestructure like mentioned above:

- fancy page with

  - special content 1 / own template for blockcontent only

  - special content 2 / own template for blockcontent only

 ...

pro drag and drop of the blocks - rendering all together on the parentpage template - con editing is not so optimal (could be better with modal editing of the childpages maybe with an extra adminpage...not so hard to code that - even for me...

Third shot would be the mentioned PageTableExented module to get it work - i don't have practise with it now but i think this would be the best solution for maximum 3-4 Blocktypes i think....but would be the last option for a usecase like yours becaus this module is not really scalable for many blocktypes.

First option if i need some kind of variants or additional field on some pages - second would be the choice for me to get real different and many blocktypes working with mentioned optional adminpage for editing that kind of pagess - third would be great for changing easy contentblocks (text, image, wysiwyg) maybe for layer, image and contentsliders, articles with different setups, portfoliopages and so on...

hope my kind of "nondev-nonsense" helps a little bit from the "amateur point of view"

In lack of skills with coding i'm allways spend a lot of time in searching how far could i get with given parts and be not that fast on the "code it like i won't it path".

- sometimes i'll get very far with think different on some things - sometimes i'm very envious that i've not really the time to learn more PHP and OOP.......but since i found processwire i think i could use both easy creating with the framework and learning faster while i've an API that i simple understand and a structure that i can easy setup to fit my/clients needs! -

kind regards mr-fan

(i've been very excited since i've read your first post here as a heavyweight C5 user calling in the PW forum - for me personally it's an honor - only by knowing your helpfulness and your postings - i think/hope this forum and community will meet your prospects)

[jordanlev]

@Soma, thank you for your response. I understand what you are saying and it will be good to keep in mind that these things are best for smaller sites, not 100,000 pages. (For my purposes, though, this is okay because I rarely build sites with more than 50-100 pages in them, so for my customers they usually value an easy and flexible editing experience above "scalability").

And I am actually building my module for use with PageTableExtended... that is the thing that is allowing this to even be possible (if you read through that forum thread I linked to you can see that someone recommended that and that is what got me started on this journey).

[jordanlev]

@mr-fan,

Thank you for your wonderful response to my question. I did not know about the "field dependencies" option (I saw it in the admin, but did not understand the use case for it... but now you have explained it very well to me!)

I think that is a great solution for some sites. The only drawback, as you said, is users cannot re-order them above and below each other.

The new module I am building uses the PageTableExtended field, and I would only expect to have 6-8 "block types" per site (if you remember in Concrete5, there are about 20 included with the core system, but most of those are not used by clients in my opinion and instead are there for system functionality like autonav, page_list, and search).

I think you will really like the module I am building because it will fill that role of letting you set up some custom content blocks that your users can re-order on the page (drag up and down). As Soma says, it will not be good for a site with 1,000's of pages, but for smaller sites (like company or non-profit organization information site) I think it will be very helpful.

Thank you again for giving me great info about how I can use ProcessWire. I really like the system so far and the community in the forums is very helpful.

Cheers,

Jordan