kongondo

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/

Unsure what's going on here. ProcessWire doesn't save URLs. They are created on the fly. You can change the name of your admin by editing the admin page. I am talking about the page Admin in the page tree, the one whose ID is 2. If you have Tracy Debugger, you can run the following code in its console, otherwise, you can run it in a template file (in that case wrap it around a check for superuser). echo $pages->get(2)->name; What does it show?

Similar issue in this thread, I think? I had a go at a solution for separately saving the original file name. This is for unzipped files though. If it is of interest, I can upload the module to a gist.

Hi @hezmann, Thanks for the purchase. I've just tested in ProcessWire 3.0.85 and it works fine. What's your setup? ProcessWire version? What's the name of your multi page field? Is that multi page field setup properly? (i.e., does it work fine outside DS) Are other page fields (single and multi) listed for selection?

From a security standpoint, ProcessWire will not allow you to directly access PHP files in a number of its protected folders (including the site/templates folder) unless that file is a template file. You can read more about it here. In that thread you'll also find a number of workarounds. Only if it's outside PW directories. See option #1 in the post I linked to above. This means you won't have access to PW's API, unless you bootstrap it, which might not be worth the effort, if all you want to avoid is creating a page .. Many people often use option #3. Post to self (same page) and include your add_client.php in that page's template file (e.g., require_once('/path/to/add_client.php/')).

That's not correct when it comes to repeaters. See @zoeck's step-by-step post above mine.