kongondo

Wild guess.. Does it also occur if using other admin themes besides UIKit?

@theo, I'll have a look. I'm not sure about the ProcessWire side of things but MB itself does check for languages when installed in a multi-language site. It doesn't activate other languages when creating a menu (which are hidden pages in admin). Hence, when saving the menu it only saves the menu title as $page->title = 'My Menu'. Since no language is specified nor is there input for other languages, the title is saved to the current language's title field. When you switch to another language, there is no menu title to display since none was saved in the first place. By the way, this is the reason why in multi-language sites, menus cannot be rendered using their titles or names. You need to pass render() the menu ID or page. Back to the missing titles issue, it's an issue I have previously considered. Back then, I came to the conclusion that it was not worth having menu items with multi-lingual titles since I couldn't think of a scenario to justify it. Your use case demonstrates that I need to revisit the issue. I'll work on this for the next version. When creating and editing menus, there will be inputs for the different languages that are available (creating) and for enabled languages (when editing) [difference here being no need to edit the title of a menu title if that language is not enabled for that menu]. Above means I'll have to change the way menus are created. It has been suggested before that MB should lose the textarea for input of menu titles (one-per-line). I think I'll go with a simple table (like the one used when adding custom menu items) with columns for each available language or a ul list or div with tabs for each available language (i.e., mimic ProcessWire's language title field). To create additional menus simultaneously, one would only have to click on an 'add another menu link/icon'. This will also resolve the issue of rendering menu items using their titles in multi-language sites. If a menu title or name is passed to render(), we will look for a menu by that title in the user's language. Sorry for the long post! Some of these are notes-to-self to be honest .

Update: Menu Builder 0.2.3 Changelog Fixed a bug where inactive pages in multi-language sites would still be displayed in menus. Thanks @thmsnhl Available in modules directory. Thanks.

@thmsnhl, Could you please test the following for me before I commit? I have tested using both the normal way of generating menus (render()) and using the method getMenuItems(). I have also tested with include children and it works fine. As for include children, ProcessWire internally takes care of the inactive pages (I guess because it uses a find()), so I didn't have to touch that. In MarkupMenuBuilder.module, please add the following code after line # 216: if(!$p->viewable($language)) continue; Any issues? Thanks.

@thmsnhl, Just to clarify, are you saying you want the German version of the page to appear in the menu but not the English one? Meaning, if viewing the site in German, we see the page in the menu, if we view it in English, we don't. No, I've never considered such a scenario but now I see I should. If we are to skip that item from the menu, if it is a parent item, obviously, its children will also be skipped.

Glad you got it sorted .

I'm not sure this is the 'hard way' . Since this is a Fieldtype, it has no admin page, unlike a Process module. So, if you need a page for it, then the page needs to be created. You can do all these using the API and the template file stuff (copying it to /site/templates/ using PHP. E.g., when installing ProcessWire, it writes to/populates config.php and moves it into place under /site/config.php. That's the approach I am talking about. If unsure how to do it, I can show you how. It is good to create the page to for your FieldtypeYourClass stuff under /admin/. That way, it won't be tempered with by non-superususers. You can even throw in a hidden status on it. A couple of my modules (including Menu Builder) use this technique. The only difference is that they do not have template files, since I post to the Process Module instead (which has a page under /admin/. So, my suggestion. FieldtypeYourClass should auto install InputfieldYourClass. In Fieldtype add the install() method. In there, you can either (a) Directly create the assets needed (page, template, template, file, etc) or (b) call a method or methods within your FieldtypeYourClass to do these or (c) Call a YourClass.php or someOtherFile.php file with the script to create these assets. Creation of template first, then create the page, then copy the templateFile.php to /site/templates/. You will need to decide if the parent of the page will be /admin/, in which case you don't want it to appear in the admin menu, so apply hide status. An alternative to creating this page is creating a Process Module to handle your ajax calls. Once, the page is created, grab its $page->id (e.g. saving it to a class property). In your Field's ___getConfigInputfields(), create a hidden input to store the $page->id. Alternatively, since you know the template used by your $page, as well as its name, you can be grabbing it like that when responding to the ajax calls, so no need for this hidden input. As for the right place for a template file, I'd go for /site/templates/. That's where template files live. Alternatively, you can have a template file there that just calls yourOtherCode.php to handle your ajax calls. If you don't want other pages to be created using your template file, you can add that setting using the API when creating the template. As for install() in Fieldtype Modules, have a look at FieldtypeOptions. It calls install(), so, yes, this can be done. When initiating your FieldtypeYourClass (have a look at FieldtypeEvents), you can make it have a setPage() method that sets your $page, hence making it available to your InputfieldYourClass. Other things you can do Lock your hidden $page (so as not to delete it by mistake). Have your FieldtypeYourClass check for the presence of the $page and throw an error if one not found (or auto-recreate it). On uninstall, delete the assets you created for the module (page, template, template file, etc). I think I've answered this above. A Fieldtype does not have its own page in the sense of a Process Module. So, you would need to create your own. Hope this helps.

OK. I see. What confused me was this. That's why I asked, why do you need to call PHP code in a modal? I'm still curious about this. About your other question... I've not tried it, but when installing a Fieldtype, like any other module, it will call install() if one is present. It is a module after all. So, try create you template, page, etc there (or call a script in install() to create the page, template, etc) .

My question is, what do you want to load in the modal? Is it a ProcessWire page? I ask because it seemed to me you wanted to include some PHP via a modal? To open a ProcessWire page in a modal is as simple as: $out = "<a href='{$urlOfThePageYouWant}?modal=1' class='pw-modal pw-modal-medium'>Open Modal</a>";// of pw-modal-large or pw-modal-small // return $out somewhere; in your init() method in YourInputfield. @others: is this always required? I'm not sure $modules = $this->wire('modules'); $modules->get("Jquery"); $ui = $modules->get("JqueryUI"); $ui->use("modal"); $modules->get("JqueryMagnific");

This is a good thing. I'd suggest that you first get a thorough grounding of the basics before plunging into creating anything. The resources suggested in the previous posts are all good. However, without a basic understanding of ProcessWire, they will not make much sense to you. People learn differently. Some people like to dive in and pick up the basics as they go along. Others (me included ) prefer to get the basics first before diving in. So, if you can go through these first, you'd be the better for it in the long run. Selectors PHP foreach loop (in case loops are newish to you) $page $pages Yes, what you asked is doable. But you will need to get those hands dirty with some custom code. It'll be fun though. Welcome to the forums .

Any reason why you have to access the PHP code in a modal? Why not just do an include or require within the module's init() ?

. Yeah, @Robin S has been on fire! I've learnt a lot about Inputfields and Hooks from his work. That's me! .

To be honest, I'm having a hard time understanding exactly what you need to accomplish . Even a simple mockup would help. Anyway, to your question. I'm having a hard time understanding your setup. For instance, you say: Do you have a single page called walks? (you say has a multi-selected page reference) OR you have multiple pages called walks. (you say I then have pages...). Secondly, where is this "walks"? Is the multi-select page reference field attached to the templates of both Continents and Countries? And more? I'm asking in order to give you a definitive answer. Irrespective, I believe what you want is either $pages->count("selector here") OR $page->numChildren("selector here"). Please note the differences as per the docs below: http://processwire.com/api/ref/page/num-children/ http://processwire.com/api/ref/pages/count/

DS in Lister is currently not fully supported. I'll be working on this in the next version (or maybe the one after that). Only one value can be selected at a time in DS. Are you trying to use it as a page field? E.g. like an AsmSelect? Repeater support is in the works (please see this post).

I think I get your setup now. Europe Germany (has page field 'regions' whose selectable pages are its children) Bavaria Hamburg Thuringia My previous solution is for when you want to list regions in a country where a 'hike' is possible. What you are after, I think, is to show only the regional hikes that have been undertaken/completed in a specific country. For instance, in the country Germany, you have several pages saved in its page field 'regions'. Those saved pages are the regions where hikes have been completed. If this is the case, then you'd have to do it a little bit differently. I'll get back to you later with suggestions. Thanks.

Yes, it can, but I am a bit confused. What is the role of the page field called regions then? From your description, you need the following relationships continent > none country > child region > child Relationships are read 'backwards', so to speak. So, region (e.g. Bavaria) is a child of country (e.g. Germany) and country is a child of continent (e.g. Europe). Continent has no 'backward' relationship (none). As for values for country and region, you can select any valid (as per DS docs) field to display for the selected child. E.g. title, population, etc, as long as those fields are present in that page. If they are present but not populated, then the select (i.e. the DS inputfield you see when you edit the page with the DS field) will be empty. If you still can't get it to work, could you please post a screenshot of your page tree, Germany, Bavaria and the Details Tab shot of your field regions? If you wish, you can also PM these or email them to me.

Oops, forgot to respond.. I don't use VSC git at all. One, I was already used to sourcetree (I tried others but they never worked for me). I feel the VSC git interface looks a little bit cramped. I guess I am also a bit jittery I'd make mistakes in there. In a sense, I don't want a swiss army knife in this case. I use VSC for the text side of things and sourcetree for what it was meant to be; a git app .

I read somewhere (can't find it now, I think it was apeisa), who stated that the test site is pretty robust.

I don't know how @adrian got there in the first place, but we do know how to confirm (works in a lot of cases?) if it is a PW site . Haven't you seen the test site by @teppo? Wow. Hmm, couldn't tell if it was a SAAS solution or something else? I only had a brief look.

Nice find! I wonder if their software is also built using PW.

OK. When I get a bit of time .

Yes, makes sense. Since the site is multilingual (but also depending on the number of fields and their complexity), no need to reinvent the wheel here, IMO. I'd output the ProcessPageEdit form. I can show you how if you don't know how to do this.

Hi @hezmann OK, progress! Good . Just to be clear. You have a page called Europe You have a page called Germany and its parent is Europe Inside the template used by the page Germany, you have a page field called regions. The page field regions has been set up to allow for selection of pages meeting a certain criteria (I mean the page field settings, not DS) Editing the page Germany, in the field regions, is Bavaria selected and saved for Germany? A screenshot of your regions field when editing Germany would help, thanks Is Bavaria published? If the answer to #5 is NO, then Bavaria needs to be saved for Germany. DS only returns saved values. A screenshot of your page tree showing Europe Germany and Bavaria would be helpful too. If the above doesn't resolve the issue, is the site remote? Any chance I could get a temporary login to have a look? Thanks.

An admin page to hold a module's config itself is not new and has been done. The bit about image upload via the module's config page, that I've not seen/heard of before. I'm wondering whether it is really worth the effort since you'd have to hook into the module class (I think), to catch the upload and save it to your admin page. Maybe it is easier to let your SEO be a process module and in there, create the interface for uploading images? The images will still be saved in your hidden admin page. You wouldn't have to hook into anything in this case. Will this module be accessible to non-superusers? In that case, you don't want them to be mucking about in ProcessWire's module pages. I'd go for a process module and save all text setting as one chunk of JSON in a text field in the hidden admin page. I use a similar approach in several of my modules, including menu builder. Just my 2p.

Yes. There is a pagination limit of 999 pages. You can configure it to go beyond that (with caution). In /site/config.php/ $config->maxPageNum = 1500;// set your limit here http://processwire.com/api/ref/config/