kongondo

Sorry for late response. I have managed to get this working via a new option. Currently testing to check it doesn't break anything. Hopefully will commit later this week.

Hi. Search the forums for 'university' as well. I know of some people here who work or have done work for Universities. I don't want to mention their names without their consent, although they've previously publicly posted about their work. Edit There's also this in the showcase forums

foreach($page->events as $event) { // empty tags in each iteration $tags = ''; // $event->options has multiple items (multi checkboxes)... // ...so, we loop through it foreach ($event->options as $o) { $tags .= $o->title . ' ';// join 'em up } // remove empty spaces $tags = trim($tags); echo "<div class='size1of2 {$tags}'>"; echo "<img src='{$event->image->url}'>"; echo "{$event->text_editor}"; echo "</div>"; } Could be made cleaner, shorter, etc... Is this a new WireArray method? I can't seem to find it

What Adrian said. Just be sure to sanitise the values you echo back directly using htmlentities, for instance, like so: $results = $sanitizer->entities($q); echo "Search results for $results";

Glad you found a solution. Thanks for helping others.

Hi Claus, Blog keeps a reference of its parent pages (Posts, Settings, Widgets, etc) in the module's settings in the DB. If you look at the DB table modules in ProcessWire, you will find a row each for each of your configurable modules. In this DB table, under the column class, look for the entry for ProcessBlog. In the data column for this entry, you will see JSON string similar to the following: { "blogFullyInstalled": 1, "blogStyle": "1", "schedulePages": 1, "commentsUse": 1, "templateFilesInstall": "2", "tagTemplatesFields": "blog", "blog": 1020, "blog-posts": 1021, "blog-categories": 1022, "blog-tags": 1023, "blog-comments": 1024, "blog-widgets": 1025, "blog-authors": 1026, "blog-archives": 1027, "blog-settings": 1028, "blog-asc": 1032, "blog-dnc": 1033, "blog-dc": 1034, "blog-rposts": 1035, "blog-rcomments": 1036, "blog-broll": 1037, "blog-tweets": 1039, "blog-pauthor": 1040, "quickPostEditor": 1 } In the above, blog refers to the main Blog page and its ID is 1020; blog-posts refers to the parent Posts page and its ID is 1021, etc. That is the missing information. If you exported your parent Blog pages verbatim, then the contents of your data column in the DB for ProcessBlog entry in your source DB should match what you want in your target DB. All you need to do is copying them over. If your parent Blog pages' IDs changed, then just edit them in the data column of the target DB. Hope this resolves your issue. Apologies couldn't answer sooner.

Sorry did not get back to you earlier Jan. It seems as well that I misunderstood your question. Please clarify. Are you looking to have a dropdown select or asmSelect or similar for each variation from which you can select and specify a download or downloads for that variation? How are you defining your digital downloads? Is each download a ProcessWire page or are they physical files stored on the server?

Visual Page Selector version 004 (released (15/08/2017) Happy to announce that the latest release of Visual Page Selector is now available for Download/Purchase. Changelog Add and close option: Please note this behaves differently if VPS used in a single page field vs. a multi page field as well as if other options are enabled such as 'Delete Images' and 'Delete Pages' or if in a Lister view in the modal. In a single page field if these 'deletes' are disabled, just clicking a page thumb in thumbs view will add the page and close the modal if this option is enabled. In other cases, the modal will be closed when the Add Page option is selected and the Apply Action button is clicked. Please also note the value of the submit button can change to 'Add' depending on the context. Ajax refreshing of Inputfield! No more page reloads once you apply an action in the modal. If you add or remove a page or delete it or its image, the Inputfield refreshes automatically. It also listens to changes made to pages in the page field if editing (in a modal @see below) a page in modal. Please note that direct Lister view actions such as unpublish, trash, etc are currently not captured in this feature. Only Adding/Removing Lister view pages via VPS Apply Actions are covered. Edit selectable and selected pages: You can configure options to edit selectable options when in the modal or selected pages already in the Inputfield (which will open a modal). Any changes you make to the selected page will be reflected in the Inputfield on save. You will see them when you close the edit modal. Support for both single and multi image fields. Please note that if you Delete and Image in a selectable or selected page, VPS will check for the next available image in the named image field(s) (named in VPS settings). If an image is found, it will be returned. Otherwise, the page will be removed from the page field. This only applies to all cases expect the combination of a List view page edit and Lister modal view where no image is required. Support for both single and multi page fields Bug fixes Apologies for the delay. Hit a couple of snags that needed to be resolved. Please test thoroughly in a non-production server first. I see a couple of JS errors in the console but they seem to be related to ProcessPageLister or JqueryCore.js. Have not been able to confirm what's causing them. The module works fine though. Please note: Docs not yet updated to reflect above changes.

@Macrura Thanks for the purchase. Sorry for the late reply. Been working on the next release which addresses all the issues raised. Done in next release. Me neither! I couldn't remember why I set it up that way! I think I confused that to mean 'allow more than one image from one page to be visible as selectable' Yep, that's how it is set up now. If image field in the selectable page is a multi-image field, grab the first image. If it is a single image field, grab that one image. In essence, VPS will always grab the first image. The issue is about the image field in the selectable pages. VPS should (and now does) work with both single and multi-image fields. Like @Macrura explained, there will be cases where you want to reuse an image field for other needs. Or imagine a case where you wanted to show related images in the frontend. For instance, for a real estate website, you may want to have different photos of one property: In ProcessWire, create a photo page with a multi images field for your property for sale. Upload various photos to the multi images field on that page, making sure that the first image is of the front of the house, for instance. Make your property page selectable in the page field you are using with VPS. Edit a page with this page field that is using VPS In the selectable pages modal in VPS, for this particular property photo page, you will see only ONE image; the first image. That should be enough for editors to know what image/selectable page to select. Underneath the hood, we/they know they are just adding a reference to the photo page (in the page field). In the frontend end, when displaying the page with the page field in #4, since the page field has a reference to our property's photo page, we can now show all the photos of our property that we uploaded in #2 . Sorry for verbosity but hope this explanation makes things clearer (not in the least for me!). As you can see, this should not affect the current workflow of one page for one image. Your selectable page with a single image field will still work as is. You will see its one image in the modal for selection and will be able to add it to your page field. Speaking of which... This is now fixed. VPS will work with both single and multi-page fields. In summary, you can have: Selectable page with a Single image field to add to a Single page (VPS) field Selectable page with a Single image field to add to a Multi page (VPS) field Selectable page with a Multi image field to add to a Single page VPS field Selectable page with a Multi image field to add to a Multi page VPS field The most important thing to remember is that in the selectable pages modal, VPS will always show one image per selectable page. It doesn't care what lies underneath. This means that you can even have a selectable page with with several image fields and if those image fields are specified in VPS image field settings, VPS will always return the first found image in the first named image field. It means that if one image is deleted or images are reordered or one image field removed or the named order of images in VPS field changes, VPS will always get the next available of the remaining images. Done! I believe this has been requested before by @Robin S but it slipped under the radar. You can now configure VPS to separately allow editing of both selectable and selected pages (i.e. both in the modal and those already in the page field) for all views (Modal: Thumbs and Lister; Page Edit: Thumbs and List). Default is not to allow editing. Page-editable access is also respected. Sorted. You now see a clean modal view with just the edit screen as well as a 'Back' button to take you back to the listings/thumbs of all items. As said above, the edit button will only be visible if you've allowed editing in modal window. If using thumbs view in the modal, and you've allowed editing of selectable pages in the modal, the selectable pages' titles will be clickable, taking you to the edit screen of the page. If a page is not editable, they will see a normal/unclickable title. In the field settings, under VPS: Modal settings, in the Page Selector View option, if you have Lister view selected, you will see more options under VPS: Lister Settings. In particular, see Limit Selectable Fields/Columns and Disallow Columns. Please see this section of the docs. No you can't, at least not from VPS side. I'm hoping to release version 4 of VPS either today or tomorrow.

That's a bug. Working on fix now. Thanks for reporting. Good point. I'll rewrite the markup to be more contextual. So, when using a single page field: select/unselect all will not show make add image/page configurable so that it will either do nothing (and let you know page field not empty) or replace the image/page in the field already Make apply action contextual + configurable to show/not show/add page/image and close modal, etc. I'll need to think these through so it may be a while before I am ready

Isn't that how single page fields work ? Not in all cases. Imagine a case where you are already in the modal and you realise you have some images saved in the page field that shouldn't be there. Rather than close the modal and remove them, you can easily remove them from within the modal and add the images you want. It is just there for convenience. No, it is not using ProcessWire's Trash. It is removing the page reference. Does it sound misleading? Remove Selected maybe?

Yes, it should be possible to add a Quick Add feature within the modal. However, how would remove (from within the modal) work (i.e., how would you indicate you want to remove an image/page)?

wire('page'); wire('user'); wire('fields'); wire('pages'); // etc...

Nothing has changed. It works just fine. If you use $input->post in your 'my-file.php', it will work as expected. If used directly in 'Copy Paste' code, it won't. For buttons, that would have to be JS from what I see. E.g., dump this after if($copy) {} in my example in the quoted post: echo '<pre>'; print_r($input->post); echo '</pre>'; exit; You will see all the POST values (but no 'submit_save' there; I guess the post is submitted in some other way) including the 'Create Copy' button, body fields, etc. So, to detect submit button, you could do the following in your 'my-file.php': if($input->post->title) { // blah blah }

Sorry, I'm half asleep . Nope, POST, should not work (a redirect has occurred, the POST is gone). A GET works because it is always there. As a workaround, JS can listen to 'submit_save.'

Maybe our wires are getting crossed somewhere . I thought the current solution meets both your and other people's/scenarios' needs. I still don't understand why users should be forced to save files in one location (/fields/). EDIT: In addition, what if I have several RM fields (either in the same or different templates) and wanted those fields to share some base JS and CSS? That's not possible if we force users to name their JS and CSS after their fields. Maybe I am missing something. Maybe if I saw a graphic/mock-up of how the RM field settings (Details Tab) would look like in your suggested solution, I would get it . For now, I will let the changes I've made stay as I believe they cater for different scenarios. If you mean within RM, the reason is that $input is not scoped locally. Have a look at this post downward. If that's not it, please let me know. Thanks. Edit: Silly me. No, POST should not work. By the time the page is reloaded (a redirect), the POST is gone. GET, on the other hand, is 'always' ther. For POST, you can JS as a workaround (to listen to 'submit_save').

Update: Runtime Markup Version 0.0.4. Changelog Enhancements to render/add file feature Added option to suppress errors if JavaScript and CSS files not found (respectively) Add /site/modules/this-modules-folder/ as a third option in Files Root Path Currently available on dev branch only. @bernhard. Using the combinations of JS/CSS has identical name to this field + their respective 'Suppress Missing JS/CSS Files Errors' should cover the need you've described above (i.e., set up your field once and load PHP + CSS + JS files with the same name as the field that are inside the folder /RM/*). That's as automatic as this is going to get .

<random-silliness> Tools: RM; Countable JS and circleChart Approach: Include one main.php , JS and CSS using RM render file option. main.php conditionally requires_once 'some-php-file.php' depending on the page being edited. </random-silliness>

Hi @elabx. No, it is not. You also need to set up permissions at the template level. This is described here. Let me know if this helps.

Sorry, OT: I'm guessing that's why you are testing Media Manager?

Quick by the ways first.. Are you sure you don't want to limit? If you are, then no need to add 'limit=0' in your selector. The easier path would be to copy renderNav(), modify that to your liking and save it as a function somewhere in your site (if you will be reusing it throughout), or in you blog-categories template file. You would then call it (if function is called renderNavCustom) as: $category_list = renderNavCustom('', $urls, '', false); $content = $category_list; Your $urls is a already a PageArray so you should be able to loop through that to grab each category Page's blog_category_image. Hope this helps.

Yes, you are right. Regarding security, I was responding to the issue about root paths in general, but now I realise what you were really after is having the field's folder as a default. Anyway, this is resolved with having the third option I mentioned. Yes, the error messages are for the dev. Maybe I misunderstand; did you have a suggestion regarding error messages? You already have this option . OK, two options, one each for JS and CSS. So, rather than having one option "JavaScript and CSS included automatically", we have split that into two for JS and CSS respectively. The second options under JS and CSS "JavaScript/CSS file has identical name to this field". That will do what you are after, but with the errors of course, if there is no file present. I think that's a good reminder about missing files. Maybe we can add an option to suppress errors about missing files (..a leave me alone I know what am doing option .). That and the identical file name options should get you your wish (of coming back later to add JS/CSS). What do you think? On the contrary! I value your honest and helpful feedback! . Exactly .

Added security...similar to wireRenderFile(). Yes you can specify a filename . FieldtypeRuntimeMarkup/fields/my-file. OK. I'll add that as a third option (or as the first option). Sure. But some people may prefer to create include folders in /site/templates/ and /site/modules/ that are shared across the site. Adding a third option above should cater for both worlds. We can't assume everyone will want to include a JS/CSS file . I don't like automating things TBH. I prefer for users to expressly declare a choice. OK. Imagine you are working on a runtime field and want to do some 'minor' JS changes. You are in your IDE and you would just have to create a new js file with the name of your field. But then you have to leave or you forgot to fully test your changes with other Inputfields present on the page and you lock up the whole page edit (yes, that's what JS will do...) . Or...you or a colleague renamed your field and forgot to rename your files... Please see above point. IMO, this is a minor inconvenience compared to the damage automation could cause. OK, maybe I exaggerate but I am not convinced automation is the best approach in this particular case. The field settings are just a click away. Yes, I could include an option to suppress errors but that's no good either. Errors need to be seen so that they can be rectified.

Hi @onjegolders, Thanks for your purchase. Apologies about the issues you are having with the module. Probably. Please try and re-install. Check for any missing files using the Network Tab. The error you see in the console is a pesky one that I've never been able to decipher/get to the root of. For now, we live with it; it doesn't affect anything. Please check your email. Thanks.

Hi, as you've noted in your other post, it is a Comments module issue. However, we can work something out, sort of. As you can see here, Comments module allows for preset values (not exactly HTML placeholders) for cite, email, website and text inputs. We can use those. In the next update, I'll make it possible to pass those as part of $options (third argument) to renderComments().