kongondo

PW-Moderators
  • Content count

    4,639
  • Joined

  • Last visited

  • Days Won

    65

kongondo last won the day on February 16

kongondo had the most liked content!

Community Reputation

4,944 Excellent

1 Follower

About kongondo

  • Rank
    Hero Member

Profile Information

  • Gender
    Not Telling
  • Location
    UK

Recent Profile Visitors

23,479 profile views
  1. 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.
  2. 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?
  3. 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.
  4. @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.
  5. 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
  6. 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?
  7. 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)?
  8. wire('page'); wire('user'); wire('fields'); wire('pages'); // etc...
  9. 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 }
  10. 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.'
  11. 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').
  12. 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 .
  13. <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>
  14. 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.
  15. Sorry, OT: I'm guessing that's why you are testing Media Manager?