adrian

Page Field Select Creator

61 posts in this topic

This module provides a way to rapidly generate Page fields and the required templates and pages for use as a drop down select (or any other Page field type).

This module will let you create a full page field setup in literally a few seconds  :)

To use, run Page Field Select Creator from the Setup Menu

  • Enter a Field Title, eg: Room Types
  • Select Options - These will become the child pages that will populate the page field select options. There are two different options.
     
    Option 1. TITLE FIELD ONLY - enter one option per line, eg:
     
    Single
    Double
    Suite
     
     
    Option 2. MULTIPLE FIELDS - the first line is used for the field names and the first field must be 'Title'. Subsequent lines are the values for the fields, eg:
     
    Title, Number of Beds, Number of People, Kitchen Facilities
    Single, 1, 1, Fridge Only
    Double, 2, 2, Fridge Only
    Suite, 3, 6, Full Kitchen
     
  • Choose the parent where the page tree of options will be created, eg a hidden "Options" parent page
  • Select a "Deference in API as" option depending on your needs
  • Choose the input field type
  • Check whether "Allow new pages to be created from field?" should be enabled.

As an example, if you entered "Room Types" as the field title, you would end up with all of the following automatically created:

  • a fully configured page field called: room_types
  • MULTIPLE FIELDS OPTION - 3 additional fields - number_of_beds, number_of_people, kitchen
  • a parent template called: room_types
  • a child template called: room_types_items (with either just a title field, or with the 3 additional fields as well)
  • a parent page called: Room Types
  • a series of child pages named and titled based on the per line entries in the Select Options textarea

The templates are configured such that the "room_types_items" child template can only have the main "room_types" template as a parent, and vice versa.

Then all you have to do is add the newly created page field to any template you want and you're ready to go!
 
You can grab it from:
 
Modules directory: http://mods.pw/5R
Github: https://github.com/adrianbj/ProcessPageFieldSelectCreator

I'd appreciate some feedback on whether others would find this useful, and if you agree with the default way the template structure and family settings are being configured. Then I'll add to the modules directory.

post-985-0-49927700-1379441662_thumb.png

18 people like this

Share this post


Link to post
Share on other sites

This is great Adrian, extremely handy!

As this is a more advantaged tool I was thinking of:

Select a template to use as child page ( with more fields in a template )

Say you select a child template with the fields: title, type & year.

Then at Select Options:

BMW, m3, 1987

Mazda, 323, 1986

VW, Golf, 2012

---

Even without this it's a real time saver !!!

1 person likes this

Share this post


Link to post
Share on other sites

Greetings,
Excellent concept! I just experimented with it briefly this morning. Will use it more later...

One of the most common newcomer misunderstandings about ProcssWire is the "missing" dropdown field. Your module gets us closer to using the depth of ProcessWire pages as selects while being easier to set up.

Thanks for doing this!

Matthew

1 person likes this

Share this post


Link to post
Share on other sites

Thanks for the positive feedback everyone. 

Matthew - that was definitely part of my reasoning for creating this. There are a few times I have wanted to set up a page field, but have gone with hani's fieldtype Select module to save time. I still think there are times when his module is more appropriate, but now I think I won't be making the decision because of the time/hassle of creating a page field setup. It is also why I chose to put "Select" in the name of the module - hopefully it will help newcomers find it more easily.

Martijn - I like where you are headed with those ideas. I think rather than selecting an existing child template (which I think is what you are suggesting), how about I allow the Select Options field to also handle multiple fields if entered? I might take a stab at that and see how it goes - stay tuned!

3 people like this

Share this post


Link to post
Share on other sites

<adrian>how about I allow the Select Options field to also handle multiple fields if entered? I might take a stab at that and see how it goes - stay tuned!</adrian>

I didn't thought about that, but thats even better, thumbs up !

Share this post


Link to post
Share on other sites
Hi everyone.

The new functionality based on Martijn's suggestions for creating the select options with multiple fields is ready. I have updated the code on Github and modified the instructions in the first post above.

Please test and let me know how it goes for you and whether there are any improvements I could make.

4 people like this

Share this post


Link to post
Share on other sites

Adrian, thanks for the update! If possible, it would have been nice to have a before (original version) and after this update text and screenshots (I know could potentially lead to a long thread and not practical with every update). It helps to compare, follow progress, etc. Not a big deal though... ;)

Share this post


Link to post
Share on other sites

Adrian I think you broke something in your latest commit.

In the option with multiple fields

The pagefield, doesn't store the Parent Page.

ps, I'm smiling while using this Module  :) 

(aside: People have to take care they're not creating a Hani amount of fields )

1 person likes this

Share this post


Link to post
Share on other sites

Works ! 

$field->notes at Select Options contain a lot of text. Maybe move the to $field->desc.

And use the $field->notes to echo out all compatible text based fields.

ps, your implementation of my suggestion is way better then how I thought about it.

Share this post


Link to post
Share on other sites

Glad to hear it's working again!

I don't mind moving the examples for the Select Options field to the desc, but I am actually not sure what you mean by:

"echo out all compatible text based fields"

Do you mean all existing text fields from the entire site? I am not sure what would make them compatible or not.

Remember that any new specified fields are created on the fly and added to the child template's fieldgroup - there is no need to have those fields already defined.

Sorry, I think I am just not understanding what you mean :)

Share this post


Link to post
Share on other sites

<adrian>Do you mean all existing text fields from the entire site? I am not sure what would make them compatible or not</adrian>

Yep that is what I meant.

Reuse of existing fields makes sense, so it would be nice to see a list of all fields that extends from FieldtypeText. ( all compatible I think )

Share this post


Link to post
Share on other sites

Good point - v4 is now available and includes a list of available text fields that can be used instead of automatically creating new ones if appropriate.

1 person likes this

Share this post


Link to post
Share on other sites

Wil test tomorrow, thanks for all your effort!

Did the testings this morning... simply love it.

Thanks for bringing in my ideas !

Edited by Martijn Geerts
1 person likes this

Share this post


Link to post
Share on other sites

Hey, no worries - I was going to be working on another new module today, but may as well get this one perfected first :)

What exactly do you think it needs and how do you see it working? I have played around with multi languages in PW a little, but since I don't really have a need, I am still not terribly literate with it yet.

Am I correct in assuming that you wouldn't really need multi-language versions of the title of the Parent page? I am thinking you'd only need them for all fields of the child pages?

So, would having separate "Select Options" textarea fields for each installed language cover everything needed?

It would be great if you could detail out how you think it would work best so I don't go down a confusing path!

Sorry for being an ignorant English speaker :)

PS Go grab v6 from Github - some restructuring of the form - layout and instructions, fixing of a bug if the field already existed, and more friendly error reporting in general.

Edited by adrian
1 person likes this

Share this post


Link to post
Share on other sites

All strings can be translated in PW.

It is as easy as. $this->_("provide your english here") or __("provide your english here") instead of "provide your english here"

Then If someone needs to translate your module the translatable strings are in there. 

  1. The translator should go to /Setup/Languages/ 
  2. Then to the language, say Dutch.
  3. There fill in the path of your module
  4. ProcessWire will detect all __('translatable strings') & $this->_('translatable strings') and present the translator with inputs.
  5. Then The translator can type in "vertaalbare tekst" go to the next, etc. translate them all.
  6. Save... Done

$field->description = __("Fringilla Sollicitudin Consectetur"); or $field->description = _$this->_("Fringilla Sollicitudin Consectetur");

To make it more fancy, use the sprintf or printf

printf(__("Created %d pages."), $count);


example

protected function buildForm1() {
  $f = $this->modules->get("InputfieldText");
  $f->name = 'fieldTitle';
  $f->label = __('Field Title');
  $f->required = true;
  $f->description = __("The title of the page field to be created.");
  $f->notes = __("Use capitals, spaces etc.");
  $form->add($f);
  .....
}
2 people like this

Share this post


Link to post
Share on other sites

Ok, now I understand - I wasn't thinking about making the module's form translatable. I thought you meant having the option for creating the selectable child pages have multi-language fields.

Thanks a lot for the detailed example - I'll take care of it now and hopefully you can let me know if I have missed anything. Should/can the name of the module itself be translatable?

Share this post


Link to post
Share on other sites

Just a little note to the translations:

If you're in a class context (extending Wire), the way to translate strings is like this: 

$this->_('Your string to translate');

Whereas in templates, there's the following syntax to use:

__('Translate me baby');

Great module :)

1 person likes this

Share this post


Link to post
Share on other sites

OK, v7 now has translations support!

Wanze - thanks for the translation info. I had just finished when your message came through. Everything seems to be working fine. Maybe you could take a look for me and let me know if I need to change any of them.

One other question for you guys - wasn't quite sure the best way to handle multiline description fields. In the case of the "Select Options" field, I think I may have made the translation more complicated than it really needs to be. Perhaps it would be better to put all in one translatable field and require the translator to include these as required. Trouble is that the title and description on the translation page don't get formatted, so it is hard to see what the intended layout actually is. Do you have any advice?

Anything I missed?

Share this post


Link to post
Share on other sites

Hey guys,

I have been playing around trying to better understand multi-language stuff and it seems to me that along with the module translation that I just set up, it would also make sense to be able to automatically fill in the alternate language(s) for the fields of the sub-pages - in my example, the values for: Title, Number of Beds, Number of People, Kitchen Facilities.

So, if you had three languages installed you'd be given three "Select Options" fields, one for each language. Based on my standard example, you'd fill out something like this:

English

Title, Number of Beds, Number of People, Kitchen Facilities

Single, 1, 1, Fridge Only

Double, 2, 2, Fridge Only

Suite, 3, 6, Full Kitchen

Dutch

Titel, aantal bedden, aantal personen, ingerichte keuken

Alleenstaand, 1, 1, Koelkast Alleen
Dubbel, 2, 2, Alleen Koelkast

Vervolg, 3, 6, volledige keuken

German

Titel, Anzahl der Betten, Anzahl von Menschen, Küchen

Einzel, 1, 1, Kühlschrank Nur

Doppel, 2, 2, Kühlschrank Nur

Weiterführung, 3, 6, komplett ausgestattete Küche

Would this be useful, or is this not how you guys handle things for the content pages for a Page field.

PS Excuse the dodgy google translations - no offense intended :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      First a note about my other modules...
      I have three existing modules that are similar in that they allow restrictions to be placed on repeating inputfields: Limit Repeater, Limit PageTable, Limit Table
      Restrict Repeater Matrix takes a different approach to the module configuration from those other modules. The module settings for Restrict Repeater Matrix are applied in the field settings rather in a module config screen. I think this new approach is better, but it means that it isn't practical to create different settings for different roles via the admin interface. Instead the module has a hookable method, allowing roles to be targeted and other advanced usages to be achieved via a hook. The result is that the module is more flexible.
      I intend to transition my other modules to the same approach over the coming weeks, but because this will result in breaking changes I will be releasing the updated modules under new names ("Restrict Repeater", etc) to avoid users upgrading via the Upgrades module without full awareness of the changes. The old modules will be marked as deprecated.
       
      Restrict Repeater Matrix
      A module for ProcessWire CMS/CMF. Allows restrictions and limits to be placed on Repeater Matrix fields.
      For any matrix type in a Repeater Matrix field you have the option to:
      Prevent drag-sorting of items Prevent cloning of items Prevent toggling of the published state of items Prevent trashing of items Limit the number of items that may be added to the inputfield Please note that restrictions and limits are applied with CSS/JS so should not be considered tamper-proof.
      Usage
      Install the Restrict Repeater Matrix module.
      For each matrix type created in the Repeater Matrix field settings, a "Restrictions" fieldset is added at the bottom of the matrix type settings:

      For newly added matrix types, the settings must be saved first in order for the Restrictions fieldset to appear. Set restrictions for each matrix type as needed. A limit of zero means that no items of that matrix type may be added to the inputfield.
      Setting restrictions via a hook
      Besides setting restrictions in the field settings, you can also apply or modify restrictions by hooking RestrictRepeaterMatrix::checkRestrictions. This allows for more focused restrictions, for example, applying restrictions depending on the template of the page being edited or depending on the role of the user.
      The checkRestrictions() method receives the following arguments:
      $field This Repeater Matrix field $inputfield This Repeater Matrix inputfield $matrix_types An array of matrix types for this field. Each key is the matrix type name and the value is the matrix type integer. $page The page that is open in ProcessPageEdit The method returns a multi-dimensional array of matrix types and restrictions for each of those types. An example of a returned array:

      Example hooks
      Prevent the matrix type "images_block" from being added to "my_matrix_field" in a page with the "basic-page" template:
      $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $page = $event->arguments('page'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && $page->template->name === 'basic-page') { $type_restrictions['images_block']['limit'] = 0; } $event->return = $type_restrictions; });  
      Prevent non-superusers from trashing any Repeater Matrix items in "my_matrix_field":
      $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && !$this->user->isSuperuser()) { foreach($type_restrictions as $key => $value) { $type_restrictions[$key]['notrash'] = true; } } $event->return = $type_restrictions; });  
      https://github.com/Toutouwai/RestrictRepeaterMatrix
    • By bernhard
      Hi,
      just stumbled over a little module that i built for my last project. it helped me to test performance of my rockdatatables module to generate 3000 random json datasets and i want to share it with you. maybe it saves some time for someone.
      https://gitlab.com/baumrock/RockDummyData/
      easy example:
      $rdd = $modules->get('RockDummyData'); for($i=0; $i<15; $i++) { // this has to be inside the for-loop to always get a new dummy $dummy = $rdd->getDummy(); echo date("d.m.Y H:i:s", $dummy->timestamp) . "<br>"; } more advanced:
      $json = new stdClass(); $json->data = array(); $rdd = $modules->get('RockDummyData'); for($i=0; $i<3000; $i++) { // this has to be inside the for-loop to always get a new dummy $dummy = $rdd->getDummy(); $obj = new stdClass(); $obj->name = $dummy->forename . ' ' . $dummy->surname; $obj->position = $dummy->job; $obj->office = $dummy->city; $obj->color = $dummy->color; $obj->start_date = new stdClass(); $obj->start_date->display = date('d.m.Y',$dummy->timestamp); $obj->start_date->sort = $dummy->timestamp; $obj->salary = rand(0,10000); $json->data[] = $obj; } echo json_encode($json); you have to store your random datasets on your own into the /data folder. there are several services for creating all kinds of random data on the web - if you know one service that allows sharing those datasets let me know and i can include common needed data into the module
    • By AndySh
      Hello!
      I need your assistance please. I purchased the module FormBuilder. Unfortunately, the module discontinued delivering customer submissions to e-mail box specified in the module settings. Direct mailing to the e-mail box works OK. The module settings stays the same and are correct, like "Send e-mail to administrator(s) is checked. The last version of FormBuilder 3.0 has been installed. Please advise how to resolve the issue becase I cannot get orders from customers anymore (((
    • By kixe
      As described in this post (https://processwire.com/talk/topic/8551-custom-urls-for-pages/?p=82742) the option 'Name Format Children' under the tab 'Family' in template settings doesn't work properly and also not as expected. I had a look inside the code and made some changes which are working properly, which offers much more options, more consistency and less code too.

      The result is the following. You have 3 Options for generating name and title, which could be combined in endless variations.
      Name is always derived from title, same like creating pages manually.
      type date: if function detects # character anywhere in the string, conversion will be: deletion of # and string will be used as format parameter for PHP date() function type field: if string is a fieldname of the parent page the value of this field will be used type string: if string doesn't fit to the 2 preceeding it will be taken as it is All parts (separated by comma) will be composed in the order of setting. You can use unlimited numbers of parts

      I made a pull request on github: https://github.com/ryancramerdesign/ProcessWire/pull/831

      Example screenshots

      Setting ...


      will result in


       
    • By kongondo
      FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup
       
      Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/
      GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup
       
      This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin).
       
      The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen.
       
      The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages.
       
      The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan!
       
      Warning/Consideration
      Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API
       
      Backend
      Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer.
       
      FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. 
       
      A very simple example.
      return 'Hello'; Simple example.
      return $page->title; Simple example with markup.
      return '<h2>' . $page->title . '</h2>'; Another simple example with markup.
      $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example.
      $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example.
      $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do:
      return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows:
      return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup')
       
      Access the field on the current page (just like any other field)
      echo $page->runtime_markup; Access the field on another page
      echo $pages->get('/about-us/')->runtime_markup; Screenshots
       
      Backend
       

       

       
      Frontend