kongondo

??

@Macrura As you can see, it works here: Does your version look like mine above? It needs JavaScript to work. I have a feeling your browser is serving the cached JavaScript files rather than the updated ones. Please clear your browser cache and/or test in incognito. Thanks.

That's very strange. It works here. PW version, PHP version?

We're still working on it :-). I'll write a progress report (post) next week.

If the pages are not viewable they won't appear in the menu/won't be returned as menu items. Make sure the templates they use have a template file and there aren't any other restrictions.

Please check your PM. In that case, you'll need to renew it here using the details I've sent you. Thanks.

Visual Page Selector version 006 (released (18/02/2019) Happy to announce that the latest release of Visual Page Selector is now available for Download/Purchase. Thanks to suggestions by @Macrura, this version includes a number of improvements one of which will require clients to relearn one thing (sorry). Changelog Ajax vs Manual Save: You can now choose whether pages added to inputfield should be immediately saved to the pagefield (via Ajax) [the default behaviour] versus have them added in a sort of "pending state". If the latter, pages will be added to the inputfield (for visual purposes) but will not be saved to the pagefield until the page you are editing is manually saved. In the modal, visually, the pages are presented as if they are in the field (i.e. similar to pages saved in the field). In the inputfield, a pending page behaves like other pages saved in the field; they can be reordered, edited, etc. This feature has several advantages including the fact that changes can be made to the page without immediately being reflected in the frontend. Please note that reloading the page being edited without saving will discard pending pages! The setting is in the Input Tab (Modal Settings) when editing the field. Trash Icon: VPS Inputfield (Thumbs View) now behaves like a PW image field in relation to deleting pages in the page field. To delete an image from a PW image field, the process simply involves marking an image for deletion by clicking on its trash icon and saving the page. Previously, VPS (Thumbs View) has required two steps (in multi-page fields); first to mark an image for deletion by clicking on its trash icon and finally clicking on the remove icon (x). In single page fields, there was no icon altogether. It required clicking on the remove icon (x). Hence, these similar actions behaved differently from each other and from PW image fields (which VPS in Thumbs View seeks to emulate and enhance). With this update, VPS now behaves similar to PW image fields across the board. To remove pages from a pagefield using VPS, simply click on their trash icons and save the page. We have removed the remove icon (x). Unfortunately clients will have to be re-taught about this change but I think the benefits outweigh the inconvenience. Modal Lister View: We've improved the visibility of pages selected for adding to a VPS inputfield. The light grey background did not provide enough contrast. We've gone for a light red (pink?).

What's their server environment? Are they on Windows?

You cannot unless a. You use <a> as the list_type OR b. You use getMenuItems() with custom menu generator. See most recent example above and this post for more information about complex menus.

Try this one: Please note that the \t and \n need cleaning up. function buildMenuFromObject($parent = 0, $menu, $first = 0) { if(!is_object($menu)) return; $out = ''; $has_child = false; foreach ($menu as $m) { $newtab = $m->newtab ? " target='_blank'" : ''; // if this menu item is a parent; create the sub-items/child-menu-items if ($m->parentID == $parent) {// if this menu item is a parent; create the inner-items/child-menu-items // if this is the first child if ($has_child === false) { $has_child = true;// This is a parent if ($first == 0){ $out .= "\n<ul class='uk-navbar-nav'>"; $first = 1; } else { $out .= "\n\t<div class='uk-navbar-dropdown'>" . "\n\t\t<ul class='uk-nav uk-navbar-dropdown-nav'>"; } } // active/current menu item $class = $m->isCurrent ? ' class="uk-active"' : ''; // a menu item $out .= "\n\t<li$class><a href='{$m->url}{$newtab}'>{$m->title}</a>"; // call function again to generate nested list for sub-menu items belonging to this menu item. $out .= buildMenuFromObject($m->id, $menu, $first); if ($m->isParent) $out .= "\n\t</div>\n";// close div.uk-navbar-dropdown $out .= "</li>"; }// end if parent }// end foreach if ($has_child === true) $out .= "\n</ul>"; return $out; } // example usage $mb = $modules->get('MarkupMenuBuilder'); $menuItemsAsObject = $mb->getMenuItems(1041, 2); $menu = "\n<div class='uk-navbar-center uk-visible@m'>"; $menu .= buildMenuFromObject(0, $menuItemsAsObject); $menu .= "</div>\n"; echo $menu;

See the post below. You can prefix the actual visible date value with a hidden sortable value (e.g. yyyy-mm-dd). Example code here. Follow the $dateSorter variable. The span with class="date-sorter" is hidden in the module's CSS file. The value in the span is the prefix. Sorting will be done based on it.

OK, we have #1 configurable and working fine (Ajax Save Yes/No). The page is added to the inputfield but not saved to the field. Such pages can be re-positioned, edited, etc, just like the other saved pages. In the frontend, they do not show up since they are not saved to the field yet. On save, the pages are added to the field. If the page is manually reloaded without saving, these pages are not saved to the field. The only snafu is that when the pages are added to the modal, in case one is not using "Close Modal On Add Page", there is no visual indication (the light grey background on table rows or if using Thumbs View, the greenish border) that the pages are in the field, which sort of makes sense because they are not yet saved to the field. However, I think they should be presented as if they are in the field. I'm not sure how to resolve this atm. Thoughts? Thanks.

HI @xportde I'm not sure what's going on in your install :-). I've never experienced this behaviour before nor have I ever received a report about it. Just to be double sure, I've just now tested (MM 011; JFU 006) with an image with a .JPG extension and it is uploaded just fine. Any error shown?

Thanks @adrian. I'll have a look (but not sure when :)). I'm swamped all around! If it's not too much to ask, could you please create an issue and reference your post above? Thanks.

That's what I am using as well. I remember going back and forth with the background colour and settled for the grey to "fit the surroundings". No there isn't and it still wouldn't work since the details are saved in the database like any other Pagefield. Reloading the page will just load what's already in the database. Making this configurable is the way to go. You would still see the added items in the inputfield, but if you reloaded the page without saving, the changes would be lost. How soon do you need this?

@gebeer, glad it's been of help :-). I can't remember when this was introduced, but yeah, it's now a requirement. I'll add the method though. Thanks! Use this instead: /** * Per the WireArray interface, return a blank Matrix * * @return WireData $matrix A blank Matrix. * */ public function makeBlankItem() { $matrix = new Matrix(); return $matrix; }

That's correct. We use Ajax to avoid reloading the page (and potentially losing other unsaved work on the page). Yes, it does. I'll have a think. It would have to be configurable (in the field's settings) in order to preserve backward compatibility. This means the default behaviour will be the current behaviour. There are two visual indicators. One, the background of the selected (table) row is highlighted (light grey). The total number of items selected are shown at the top of the results. Maybe the light grey background is too subtle? Which Admin Theme are you using? I got this feedback RE Media Manager as well. The only solution I could think of was floating add and remove buttons. I haven't gotten round to coding one yet. Yes, you are right, marking items for removal alone will not remove them. I get your point, but I am not sure how to deal with this one. I don't want to change the behaviour now and break backward compatibility. I'll have a think whether to make this configurable as well, i.e. current behaviour (2-step process) versus "marked/selected image will be deleted on save";

https://processwire.com/api/ref/config/

Have a look these examples: you will need to use getMenuItems() method.

Admittedly I don't use this PHP syntax but aren't we missing a second = ? Otherwise we are assigning instead of comparing :-).

Nice! What admin theme is that?

Thanks for resolving the issue! I don't get the bit about only used in admin; do you mean use a condition to check whether in admin? If you tested and it works find in the frontend as well with your mod, that's great! If the mod affects the frontend, then we can do the condition check for admin. It's been a while since I looked at the module and the master branch is beginning to really lag behind the dev branch. If you can write some code for me here rather than a PR, I'll appreciate it, thanks.

Glad you got it sorted :-). Yes. You can change the limit and lots of other similar stuff by using the filters under "What media to show". You can also configure and save a filter to be used as the default. Results can be filtered by a single or multiple criteria such as limit, title, description, tags, published, modified, etc. You can use operators such as contains text, equals, etc. The results are automatically refreshed when a filter is applied. Please see the two examples below. The first involves filtering the results directly without creating and saving the filter, although the filter will be cached and applied until the cache expires. The second one shows you how to create and save a filter that you can subsequently set as your default filter. This is especially useful if you are working in teams that need results tailored to their workflow. Please note that you may at times need to reset (rather than refresh) filters for a new one to apply due to caching. Although you can clear this type of filter directly, subsequent reloads with reload the filter as well. Hence, this type of filter persists across sessions. In the "What media to show" panel, the reset icon is the second one after the filters tab. The first icon is for refresh. Direct Filter Configure, Save and Apply Filter In this example, we classify a number of items using a common tag, 'people'. We then create a filter titled People which limits the results returned by number (2) and tag (people). Please note that you do not have to use tags if all you are interested in is limit. We only use it to enrich the example. Finally, we set People as the default filter. As a by the way, you can also use tags to filter items in the frontend using a ProcessWire selector ?.

My bet is that there's an upload that didn't get completed and/or a media that, for some reason, did not get deleted and the process is stuck in memory. Is it possible to try the following for me please? If you change the setting for "replacing duplicate media", to either "skip" or "rename" the uploaded media, does normal uploading work? With the setting back to "replace duplicate media", are you able to narrow down what particular image(s) leads to the errors? For instance, the error always occurs when you try to "upload and replace" a media called "Cats". We can then visit the "Cats" media page to edit it and see if there are any errors there. Are you able to edit your media pages to confirm that they all have images (i.e. they are not empty)? Are the images JPGs or PNGs or both?

Thanks for testing. The error says means that the media has not been found. It means that the media field is empty, for some reason, which is strange. The line where the error occurs tells me that in your settings you specify that uploading a duplicate media should replace the one that already exists in the Media Manager Library. Using these settings, I have tried to replicate the error that you are getting but everything works fine. The old media is replaced fine. Could you please provide more details? What sort of media are you getting the error with? E.g. images If images, are they huge images? ProcessWire + PHP Versions What upload mode are you using? I've tried with both 'upload anywhere' on and off and I get no errors. It could be that you had an unfinished upload (maybe PHP ran out of memory). Could this be the case? I have modified the file where the error is occurring to at least suppress the error. I've emailed it to you.