Jump to content
adrian

Page Field Select Creator

Recommended Posts

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://modules.processwire.com/modules/process-page-field-select-creator/
Github: https://github.com/adrianbj/ProcessPageFieldSelectCreator
 

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

  • Like 21

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 !!!

  • Like 1

Share this post


Link to post
Share on other sites

Very clever and useful. I'll use it for sure!

  • Like 1

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

  • Like 1

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!

  • Like 3

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 !

  • Thanks 1

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.

  • Like 4

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 )

  • Like 1

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.

  • Like 1

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
  • Like 2

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
  • Like 1

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);
  .....
}
  • Like 2

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 :)

  • Like 1

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 Sten
      Hello
      Till now I hacked something with the twig template but it works no more with new PW versions so I look forward to create a module. I am working on a site in multiple languages : French, English, Italian, German, Spanish, Portuguese, Hebrew, Russian. The new posts are entered in any language with a field for language. Till now, I got twig files to get the translations with constants defined for each part of the pages.
      So I'd like to create a module to include theses files added according to the url /fr/en/...
      Have you some observations to do before I begin about the direction to take ?
      Thank you
    • By ukyo
      Mystique Module for ProcessWire CMS/CMF
      Github repo : https://github.com/trk/Mystique
      Mystique module allow you to create dynamic fields and store dynamic fields data on database by using a config file.
      Requirements
      ProcessWire 3.0 or newer PHP 7.0 or newer FieldtypeMystique InputfieldMystique Installation
      Install the module from the modules directory:
      Via Composer:
      composer require trk/mystique Via git clone:
      cd your-processwire-project-folder/ cd site/modules/ git clone https://github.com/trk/Mystique.git Module in live reaction with your Mystique config file
      This mean if you remove a field from your config file, field will be removed from edit screen. As you see on youtube video.
      Using Mystique with your module or use different configs path, autoload need to be true for modules
      Default configs path is site/templates/configs/, and your config file name need to start with Mystique. and need to end with .php extension.
      Adding custom path not supporting anymore !
      // Add your custom path inside your module class`init` function, didn't tested outside public function init() { $path = __DIR__ . DIRECTORY_SEPARATOR . 'configs' . DIRECTORY_SEPARATOR; Mystique::add($path); } Mystique module will search site/modules/**/configs/Mystique.*.php and site/templates/Mystique.*.php paths for Mystique config files.
      All config files need to return a PHP ARRAY like examples.
      Usage almost same with ProcessWire Inputfield Api, only difference is set and showIf usage like on example.
      <?php namespace ProcessWire; /** * Resource : testing-mystique */ return [ 'title' => __('Testing Mystique'), 'fields' => [ 'text_field' => [ 'label' => __('You can use short named types'), 'description' => __('In file showIf working like example'), 'notes' => __('Also you can use $input->set() method'), 'type' => 'text', 'showIf' => [ 'another_text' => "=''" ], 'set' => [ 'showCount' => InputfieldText::showCountChars, 'maxlength' => 255 ], 'attr' => [ 'attr-foo' => 'bar', 'attr-bar' => 'foo' ] ], 'another_text' => [ 'label' => __('Another text field (default type is text)') ] ] ]; Example:
      site/templates/configs/Mystique.seo-fields.php <?php namespace ProcessWire; /** * Resource : seo-fields */ return [ 'title' => __('Seo fields'), 'fields' => [ 'window_title' => [ 'label' => __('Window title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'attr' => [ 'placeholder' => __('Enter a window title') ] ], 'navigation_title' => [ 'label' => __('Navigation title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'showIf' => [ 'window_title' => "!=''" ], 'attr' => [ 'placeholder' => __('Enter a navigation title') ] ], 'description' => [ 'label' => __('Description for search engines'), 'type' => Mystique::TEXTAREA, 'useLanguages' => true ], 'page_tpye' => [ 'label' => __('Type'), 'type' => Mystique::SELECT, 'options' => [ 'basic' => __('Basic page'), 'gallery' => __('Gallery'), 'blog' => __('Blog') ] ], 'show_on_nav' => [ 'label' => __('Display this page on navigation'), 'type' => Mystique::CHECKBOX ] ] ]; Searching data on Mystique field is limited. Because, Mystique saving data to database in json format. When you make search for Mystique field, operator not important. Operator will be changed with %= operator.
      Search example
      $navigationPages = pages()->find('my_mystique_field.show_on_nav=1'); $navigationPages = pages()->find('my_mystique_field.page_tpye=gallery');
    • By Robin S
      This is a module I made as an experiment a while ago and never got around to releasing publicly. At the time it was prompted by discussions around using Repeater fields for "page builder" purposes, where the depth feature could possibly be used for elements that would be nested inside other elements. I thought it would be useful to enforce some depth rules and translate the depth data into a multi-dimensional array structure.
      I'm not using this module anywhere myself but maybe it's useful to somebody.
      Repeater Depth Helper
      This module does two things relating to Repeater fields that have the "Item depth" option enabled:
      It enforces some depth rules for Repeater fields on save. Those rules are:
      The first item must have a depth of zero. Each item depth must not be more than one greater than previous item depth. It provides a RepeaterPageArray::getDepthStructure helper method that returns a nested depth structure for a Repeater field value.
      Helper method
      The module adds a RepeaterPageArray::getDepthStructure method that returns a multi-dimensional array where the key is the page ID and the value is an array of nested "child" items, or null if there are no nested children.
      Example

      The module doesn't make any assumptions about how you might want to use the depth structure array, but here is a way you might use it to output a nested unordered list.
      // Output a nested unordered list from a depth structure array function outputNestedList($depth_structure, $repeater_items) { $out = "<ul>"; foreach($depth_structure as $page_id => $nested_children) { $out .= "<li>" . $repeater_items->get("id=$page_id")->title; // Go recursive if there are nested children if(is_array($nested_children)) $out .= outputNestedList($nested_children, $repeater_items); $out .= "</li>"; } $out .= "</ul>"; return $out; } $repeater_items = $page->my_repeater; $depth_structure = $repeater_items->getDepthStructure(); echo outputNestedList($depth_structure, $repeater_items);
       
      https://github.com/Toutouwai/RepeaterDepthHelper
      https://modules.processwire.com/modules/repeater-depth-helper/
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
    • By MoritzLost
      This module allows you to integrate hCaptcha bot / spam protection into ProcessWire forms. hCaptcha is a great alternative to Google ReCaptcha, especially if you are in the EU and need to comply with privacy regulations.

      The development of this module is sponsored by schwarzdesign.
      The module is built as an Inputfield, allowing you to integrate it into any ProcessWire form you want. It's primarily intended for frontend forms and can be added to Form Builder forms for automatic spam protection. There's a step-by-step guide for adding the hCaptcha widget to Form Builder forms in the README, as well as instructions for API usage.
      Features
      Inputfield that displays an hCaptcha widget in ProcessWire forms. The inputfield verifies the hCaptcha response upon submission, and adds a field error if it is invalid. All hCaptcha configuration options for the widget (theme, display size etc) can be changed through the inputfield configuration, as well as programmatically. hCaptcha script options can be changed through a hook. Error messages can be translated through ProcessWire's site translations. hCaptcha secret keys and site-keys can be set for each individual inputfield or globally in your config.php. Error codes and failures are logged to help you find configuration errors. Please check the README for setup instructions.
      Links
      Github Repository and documentation InputfieldHCaptcha in the module directory (pending approval) Screenshots (configuration)

      Screenshots (hCaptcha widget)

       
       

       
×
×
  • Create New...