adrian

It doesn't really help you, but this is the culprit line: https://github.com/ryancramerdesign/ProcessWire/blob/a8024bb49785370aa2e3867bd683094663cfeabf/wire/core/Pagefiles.php#L264 Ryan may consider adding @ to the list of allowed characters. I don't think there are any reasons why it needs to be removed. I think historically it wasn't allowed in filenames, but now should be fine. Some more reading: http://en.wikipedia.org/wiki/Filename#Comparison%5Fof%5Ffile%5Fname%5Flimitations http://superuser.com/questions/358855/what-characters-are-safe-in-cross-platform-file-names-for-linux-windows-and-os

Firstly, you need to make the name of the checkbox field an array by appending [] echo "<input type='checkbox' name='type[]' value='{$t->id}'>{$t->title}<br>"; Then take a look at Ryan's example: http://processwire.com/talk/topic/3061-how-to-save-field-page-type-checkbox/?p=30229

Thanks for the feedback on that - sounds like you have a better solution anyways! In case you, or anyone else misses the note in the edited first post, it is now available from the modules directory: http://mods.pw/5R Thanks again Martijn for all your help testing this - much appreciated!

Hey Nic, Just playing around with multi-language fields for the first time and noticed that if I set the Title field to "PageTitleLanguage", then the titles for all the results in the tree are [object Object] Thanks

I don't think there is any way to set a page status locked to hidden without also preventing editing, either by user access permissions, or the locked status option. However, it is easy to prevent the pages of a template from being displayed in your menu. If you are using Soma's Markup Simple Navigation module: $treeMenu = $modules->get("MarkupSimpleNavigation"); echo $treeMenu->render(array("selector" => "template!=category-site)); If you are rolling your own menu, then you can still use the template!=category-site in your selector which populates the page array for your menu. Hope that helps. If you need a more specific example, show us the code you are using and we'll show you what needs to be done.

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

If you are converting from WP to PW you should look at Ryan's case study here: http://processwire.com/talk/topic/3987-cmscritic-development-case-study/

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?

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?

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.

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.

Just a heads up that in the modules directory, this has two authors listed: martijn and geerts. Would be nice to have that corrected so it is together with all your other modules under: http://modules.processwire.com/authors/martijn-geerts/

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

Oops - sorry about that - try v3 now on Github

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.

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!

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

Thanks Ryan, I have just updated the module on the module's page with v1.0.3. This version moves many of the settings to the module configuration page, rather than on a per field basis. I dealt with the leading zero issue by appending a tilde on settings save and removing it when loading the settings, so it is transparent for the user. I have also update the instructions in the first post above. If anyone has any changes they'd like to see, please let me know.

Here's another bit of code from Ryan that might prove helpful: http://processwire.com/talk/topic/3299-ability-to-define-convention-for-image-and-file-upload-names/?p=32623 It is not for random filenames, but it does show how to set up a file renaming module

It really is personal preference, but I think Ryan would most likely go with the first: Here are a couple of relevant threads/posts: http://processwire.com/talk/topic/4439-when-do-we-need-curly-brackets/ http://processwire.com/talk/topic/3835-sorting-pages-by-multiple-values/?p=37797

Replace: src:'assets/img/overlay.png' with: src:$page->bgimage->url EDIT: horst has it right - I wasn't awake apparently

In the selector: $newsposts = wire("pages")->find("parent=/news-articles/, $category, template=TUT_news, limit=3"); you should just need to add: sort=-created eg: $newsposts = wire("pages")->find("parent=/news-articles/, $category, template=TUT_news, limit=3, sort=-created"); That will sort your posts in reverse order (-) of created date/time.

Hey Martijn, I just sent you a pull request to add the ability to specify the maximum filesize for an image once inserted in an RTE. I needed this functionality because clients were uploading very high resolution images and embedding those - nasty! Training only works for some people and only some of the time The interceptor will automatically compress this image until it reaches the limit specified in the module settings. If the limit is set too low, it can obviously result in some poor quality images. I wonder if it would be good to have a bit of a sliding scale for this setting based on the physical dimensions that the image is going to be displayed at. Let me know what you think and definitely feel free to ignore, or give me your ideas for a different approach. I am also open to making this a separate module if you'd prefer.

Ah, sorry - been on 5.4 for so long I forgot about this. Yes, repeaters aren't supported yet. For the moment I'll add that to the list of fieldtypes to ignore so at least there won't be an error. Btw, the last update also now handles RTE links that have been processed by the PageLinkAbstractor module. EDIT: Committed version with those small fixes. NB that the check to ignore repeaters is currently only on the export, so you would need to export again to check.