kongondo

@mrkhan, If by child pages you are referring to the children of the pages you have selected in your menu_page page field, then the following (slightly verbose) code should do it. This will create a 2-level menu. For anything deeper use a recursive function - there's plenty right here in the forums. $out = ''; $out .= '<ul>'; foreach($page->menu_page as $item) { $out .= '<li class="top"><a href="#">'. $item->title . '</a>'; if ($item->numChildren) { $out .='<ul>'; foreach ($item->children as $child) { $out .= '<li class="child"><a href="#">'. $child->title . '</a></li>'; } $out .='</ul>'; }//end if child items $out .='</li>'; } $out .='</ul>'; echo $out;

Hi...just a quick one to let you know that I have this working...rows and columns grow with each new row and column pages or shrink when these are deleted/trashed/hidden/unpublished. I need to do a couple more tests and cleanup the code (remove hard-coded stuff, rename the db table columns to something more generic, e.g. matrix_row and matrix_column, etc) . I also want to make the Fieldtype more configurable - e.g. ability to use a PW selector to find pages to populate rows and column headers (x and y axes). However, not sure if the Fieldtype duplicates what is already available in PageTable? Anyway, here's some screens.. matrix (InputfieldMatrix) db table (FieldtypeMatrix)

This module Fieldtype Image Extra (multi-language) should be able to handle that I should think: http://mods.pw/82 Support: https://processwire.com/talk/topic/7910-module-fieldtype-image-extra-multi-language/

You can add as many pages as you want. Try it. There is no limit. I was just using 4 as an example... . You can order them the way you want. Depending on how you setup the menu_page field under Input Tab -> Selectable Pages, you can limit the pages that are selectable as menu items. By limit here I mean you could limit them to child pages of a particular parent, or pages using a particular template, etc (I don't mean a limit on numbers!)

Sure, I can and I have tested this and it works but let me show you how to do it without repeaters (it's just an unnecessary step in this case IMO)...assuming you want a single level menu. This is for a single level menu Edit and change your page field (menu_page) to be a Multiple pages (PageArray) While still editing it, on the Input Tab, scroll down to Input field type * and select an appropriate input, maybe *AsmSelect. Save Add menu_page to your top-menu template Edit the page 'top-menu' and select your menu pages Output your menu using code similar to below (add code to top-menu.php)..or adjust it if adding to your head.inc (i.e use $pages->get to get the Top Menu page first) foreach($page->menu_page as $item) echo '<li class=""><a href="#">'. $item->title . '</a></li>'; Screenshot

Can you confirm if your page fields are for single or multiple pages? If multiple and if you have set up as shown in the screenshot below, then you need to nest yet another foreach! If you really want to continue using repeaters for this then you probably want to write a recursive function to output your menu. Is this your setup? If yes, you would need to loop through $menu_item as well...

I don't understand this. It doesn't stop you from using a page field directly in your page rather than via a repeater...anyway... I am not very good with the alternative PHP syntax you are using so not sure if your <li> is in the right foreach. Is this a development/local server you are testing this on? Turn on debug mode to true if you haven't already. OK, let's determine that $menu_page is actually an array. What do you get when you do the following? foreach($top_menu->menu_pages as $menu_page) { echo gettype($menu_page); exit; }

Mrkhan...welcome to the forums and PW... I am wondering why do you need repeaters for this? You only have for pages in them and you are not exactly 'repeating' anything...You can simply have a multiple page field added directly to your page (the one using the top-menu template) and select your menu pages directly rather than going through repeaters...OK, back to your question... Whereas you are looping through your repeater (it returns an array), you still have one more array to loop through - your page field is a multiple page field. So you need to foreach it inside your repeater foreach...Also, you still have $menu_page->tile that Adrian pointed to...

OK, will TRY post a prototype here soon...

@Gazley. None whatsoever from the point of view of upgrading Blog. Upgrades don't overwrite anything outside /site/modules/ProcessBlog/. Nothing is reinstalled, your content, fields, etc are not affected. You could even rename your Blog pages and it will still work fine. Only two don't dos: don't change the IDs of the main Blog pages in the db and don't rename Blog fields and templates

OK, then your table illustration is a bit confusing. Do you mean you want to store the values of both pagefield-A and pagefield-B in one inputfield? E.g. store x,y in the inputfield? Or do you want to store them separately e.g. pages_id | x (pageField-A values)| y (pageField-B values) 5022 | 4 | 8 5038 | 7 | 10 5045 | 15 | 12 If that is the case, it might actually be less work to start from Soma's FieldtypeDimension - https://processwire.com/talk/topic/4081-fieldtypedimension/. I have a feeling though that I am not getting you correctly and I might be mixing up what you want to be visible in the Inputfield vs the structure of the database table for this Fieldtype

Could you show us the code you tried with FieldtypeEvents? Do you also want the first column and header rows (pageField-A-valx and pageField-B-valx) to be visible in the inputfield or just the calculated values? Maybe first solve this (if you can ) outside the Fieldtype then try and implement it in FieldtypeEvents. What sort of calculations are you carrying out by the way, i.e. y * x?

Writing quickly but these should point you in the right direction...to implement in your code above // retrieve all images with tag 'potrait' $images = $page->images->findTag('potrait'); you can then iterate $images. If in a selector, then search using the subfield tags: // Find pages containing an image with the single (1) tag: 'potrait' // This will only match images with 1 single tag of 'potrait'. $mypages = $pages->find("images.tags=potrait"); http://processwire.com/api/fieldtypes/images/ Btw, just wondering why your tags have to be manually entered in some field? Why not use the child pages themselves as tags? Then you can use pagefields to pull in those tags? E.g. a child paged titled 'potrait'

For security reasons, you can't directly access files like that within the the PW templates directory (as well as others). Hmm...I always thought it's only PHP files that this restriction applies to but possibly HTML files as well? Somebody more knowledgeable will clarify Possible workarounds if restriction also applies to HTML files: use an include in a template file place the file outside PW directories and reference it from those locations

@ESRCH...welcome to the forums. Read you question quickly. Maybe this topic can help? https://processwire.com/talk/topic/5441-kind-of-calculated-field/ It's about creating a hidden field to store a calculated value on the fly. See posts #2 and 3

...yes, and it's faster than count() https://processwire.com/talk/topic/3094-get-first-image-and-title-of-children-pages/?p=30470 https://processwire.com/talk/topic/3094-get-first-image-and-title-of-children-pages/?p=30608

@Jan....minus the urlSegments bit, that's exactly one of the answers I provided in my post above (#2)...which @Manol didn't consider as the solution

I'd say we don't. Maybe @kixie can collaborate with @geniestreiche to enhance the existing module(s)? Whilst I wouldn't want to discourage the enthusiasm of budding module developers, I'd say this is something we need to carefully consider and strike a good balance about. There's enough lessons from our neighbours Drumlapress about this . Just saying..

See options #1 (post to script outside PW directories) and 3 (post to same page) here: https://processwire.com/talk/topic/407-processing-contact-forms/?p=3106 If you go with option #3 you can intercept right within same page, call your module, do your stuff and return the data Btw, in case you were not aware...https://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/ if($config->ajax) { // page was requested from ajax // can optionally include external php scripts // call your module and do stuff }

@Kixie, Nice effort! Thanks. Not sure you know we already have a similar module? http://mods.pw/2y - ProcessPageHidden and one for un/publish - http://mods.pw/2z - ProcessPagePublish Btw, both yours and the ones I linked to are not really Process Modules

@Raymond - if that's what happens then it is working correctly . Blog does not automatically associate permissions and roles. That would be assuming too much. It is left to you to set up. To help you, it creates the role 'blog-author' and a permission 'blog'. The role 'blog-author' is used to find and list, uh, Blog Authors' posts. The permission 'blog' is used to grant view access to the Blog Dashboard. So, as per normal PW access control setup, you will need to assign roles/permissions to your users at both the access and template level. You can still create additional permissions/roles to fine tune who can post, publish, edit, posts, etc. So, if you want your user to view the dashboard you can add the permission 'blog' to the role 'blog-author' (or any other role you create) and give your user that role. If you want them to access the Blog pages tree, you can do that at the template level. E.g. create a role 'blog-editor', and use that to control template-level permissions for Blog pages (view, edit, delete, etc). You can take advantage of PW's cascading permissions feature (i.e. children inherit parents'). Please note that if you do not want users to be able to delete Blog posts at the template level then you should also not give them access to the Blog Dashboard since they will be able to delete posts anyway. I have not had the need to add such an access control at the Blog Dashboard level beyond checking if they have 'view permission' ('blog') and for the 'Cleanup' utility, that they are supersusers.

Are you looking for an affirmation or a code example?

About renaming the module...(it isn't a process module ) https://processwire.com/talk/topic/741-a-guideline-for-module-naming/?p=6267 https://processwire.com/talk/topic/1313-modules-process-and-the-difference/

@Rob, Have you enabled URL segments in your template as Soma suggested? If you don't know how to do that, happy to explain..

Ha! I didn't notice that . Well I hope I said something useful