Leaderboard

Just to give you a simple example of why I think this is a must-have feature. I am working on a site where the staff are mentioned in blog posts, but obviously if a user types in the person's name, the first result they want to see is the staff member's info page, rather than the blog posts that mention them. Awesome - I'll hold off on doing this myself.

Interesting idea — added to the backlog ? I have a "mostly functional" proof of concept of this on one of my sites. This will likely be the next feature I work on after I get current dev branch merged ? ?‍♂️

Thanks for the explanation @teppo - I started to realize how it works as I played around with things. I like your initial thinking, although I do think it's slightly confusing, but I also don't think it's worth your time to reconfigure. I have another feature request for you ? I know I could do this if I went with the json rendering of results and then manipulating and rendering myself, but I think it would be great if the "Indexed Templates" config setting was an ASM Select field so we could choose template order. I'd love to see this template order used to group and order the rendered search results. I think it would be nice to have the option for using the template label to add group headings to the results. It would also be good to have an option for presenting these template grouped results into different tabs - a bit like the PW website's search results. Actually, speaking of the PW website search functionality, maybe adding an automatic option for AJAX rendering of results below the search box would also be nice. I know all of these are possible with manual rendering, but I think we could all benefit from an inbuilt implementation. BTW, this module really is awesome - thank you!

@adrian, how about this: By default all the config fields are displayed so you can use Ctrl+F, but when you click a quick link it hides all the config sections apart from the active one. This removes the clutter around the section the user wants to focus in on. Here is the CSS and JS if you want to play with it: #tracy-quick-links .InputfieldContent ul { list-style-type: none; padding: 0; overflow: hidden; } #tracy-quick-links .InputfieldContent ul li { float: left; padding: 0 5px 5px 0; } #tracy-quick-links .InputfieldContent ul li a { background: #e3e9ef; color: #333; display: block; padding: 1px 10px; border-radius: 3px; } #tracy-quick-links .InputfieldContent ul li a:hover { text-decoration: none; background: #d9e1ea; } #tracy-quick-links .InputfieldContent ul li a.active { background: #e83561; color: #fff; } $(document).ready(function() { var $quick_links = $('#tracy-quick-links'); var $config_fields = $quick_links.nextUntil('#wrap_uninstall'); $quick_links.on('click', 'a', function(event) { event.preventDefault(); if($(this).hasClass('active')) { $(this).removeClass('active'); $config_fields.show(); } else { $quick_links.find('a').removeClass('active'); $(this).addClass('active'); $config_fields.hide(); $($(this).attr('href')).show(); } }); });

Hi all, I won't always post here when I update Tracy, but I will when I think the update is an important bug fix that you really should update to. There was a bug in the new 2.8 branch of core Tracy package that was sometimes causing recursion and really slow load times and sometimes memory exceeding errors. This has been fixed and is available in 4.21.41 of Tracy released today.

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

@BillH thank you very much, that was exactly what I was looking for.... I only had to modify the following line slightly, otherwise it gives me problems with my date (fieldtype: datetime). // old line $originalValue = $page->date_field; // modified line to my needs $originalValue = strftime('%Y-%m-%d', $page->getUnformatted('date_field')); Thanks cu Ralf If someone wants to see the whole code again...

"form_action" is indeed part of the "render_args" array. The $args array that SearchEngine::renderForm() (actually implemented by SearchEngine\Renderer::renderForm()) takes in is also the "render_args" array from the parent scope — so this depends (or at least it should depend) on which context you're defining this argument: If you're defining it via site config or by manually calling SearchEngine::setOptions(), you should put it within the render_options array item, which itself is an array ($config->searchEngine = ['render_options' => ['form_action' => '...']]). If you're calling SearchEngine::renderForm() with an args array, you should pass it as a top level item ($searchEngine->renderForm(['form_action' => '...'])). Please let me know if this description doesn't match actual behaviour though. That is how it should work. I must admit that I manage to confuse myself with these arguments every now and then. While I thought this would be the best approach while building the module, right now I'm not so sure anymore — the basic idea here was that when you're specifically calling render* methods, you shouldn't have to worry about anything other than the render args. Argument handling is one of the things I might still change a bit once I decide that the module is ready for a 1.0 release... ? Makes sense to me. Since theming support was initially added I've been using either the default theme as-is, or completely custom markup and styles, so the whole theme concept is somewhat "underdeveloped" at the moment. I've added this on my backlog for now.

Yeah, I agree - I was confused by that when I was setting that stuff up in Tracy.

Sorry @teppo - another question / request for you - what do you think about being able to store theme folders in /site/templates/SearchEngine/themes to avoid any issues with overwriting during updates, and also so it's cleaner for version control?

That's a different context: it seems to me that Tracy hooks after PageFinder::getQuery() and uses the getQuery() method of returned DatabaseQuerySelect object. In my case I'm calling PageFinder::getQuery() instead. It's potentially a bit confusing that PageFinder::getQuery() returns an object that has getQuery() method, but these are actually two unrelated things... ? Technically I could do the same thing in SearchEngine, but it feels "less straightforward" ?

Thanks @adrian! Came to the same realization here in the meantime: PageFinder::find() sets the default value, but PageFinder::getQuery() doesn't, which means that in this case I do indeed need to specifically define returnAllCols. I'll commit a fixed version soon. I'm accessing this method directly for debug purposes (in order to display the generated SQL query in the Debugger class), and that's likely the only situation where one might run into this.

Sorry about that - I was running 3.0.171. I just updated to 3.0.172 and still seeing the notice, but now it's on line 1493

Hey Adrian! First things first: which version of ProcessWire is this on? Line number doesn't seem to match either current master or dev branch. Error you're seeing looks easy to fix, but at least in current master or dev branch of the core PageFinder takes care of setting default value for this option. My guess would be that there's a version of the core that doesn't set the default value, but I'd like to make sure before applying a "fix", just in case ?

It's something I built for my own use. I am constantly creating new / modified versions of it for all sorts of imports. Here is a copy of what I am currently using for that version: Obviously you'll need to make a lot of changes to have anything useful to you, but it's a good starting point. Also note that I am making use of this CSV library: https://github.com/parsecsv/parsecsv-for-php so you'll need to grab that so it can be included.

Great, the UnorderedListToPages Action did just what I needed. Is that Import Media action available somewhere is just in your custom use?

Sorry for the delay @lpa - the latest version will now let you replace with an empty value.

You gotta thank @Robin S for the idea and implementation of those: https://processwire.com/talk/topic/24932-feature-requests/?do=findComment&comment=210091

@adrian Just updated and got the debug bar back, great ? Thanks for the help! Loving the new Quick Links Buttons by the way!

mod_security is known do cause all manner of problems with various systems. One can get them under control, but from my experience most people just disable it.

The client's IT engineer found the issue last night. Their new live server had 'apache mod_security' enabled and that was preventing the AJAX response from getting through. As soon as it was turned off the AJAX response was received and image uploads started working. I'd be interested to see if anyone has had this issue and if it's considered bad practice to have this turned off long-term.

Both client-side and server-side resizing strip the EXIF data. If you are able to get the EXIF data with the server-side option then possibly you are hooking before the resize and might be able to access and save the EXIF data then. But in my opinion PW shouldn't be stripping any data from an uploaded image that is to be the "original" from which variations are derived. There's an open issue about this, with fixes for both client-side and server-side resizing (ImageMagick only): https://github.com/processwire/processwire-issues/issues/1055 Just hoping and waiting for it to be applied to the core...

@Pete - your "allowed superuser" option is now available in the latest version. @Robin S - I implemented your quicklinks filtering - I think it's a really nice improvements - thanks! Also, I haven't forgotten about your shortcut links panel idea - it's next on my list.

I'd suggest hooking on Pages::saveReady. So, you could put something like this (not tested) in ready.php: $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); if($page->template == "relevant-template") { $originalValue = $page->date_field; $newValue = date("oW", strtotime($originalValue)); // or whatever you need to do $page->set("integer_field", $newValue); } }); Note that if hooking on saveReady you don't need to save the field or page because the page is about to be saved.

My understanding is that there are three hookable methods that you can use if you want detailed control of which pages are viewable, editable and "listable". Viewable = user may view the page on the front-end. Example hook in /site/init.php: $wire->addHookAfter('Page::viewable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not viewable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not view the page $event->return = false; } }); Editable = user may edit the page in ProcessPageEdit. Example hook in /site/init.php: $wire->addHookAfter('Page::editable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not editable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not edit the page $event->return = false; } }); Listable = user can see the page in ProcessPageList. Note: superusers are not affected. Example hook in /site/init.php: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not listable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not see the page in ProcessPageList // And therefore may not see its descendant pages either $event->return = false; } }); There's a catch to be aware of with this last hook. Page::listable only affects ProcessPageList and not other parts of the admin. If the existence or title of the page must remain private then you'll need to handle the following separately: Admin search (AJAX results) Admin search (results page if user hits enter) Lister (aka "Find") Maybe other places such as Page Reference fields I think @adrian has some experience with hiding pages from these places and might have some suggestions. Edit: In my opinion it would be nice if PW used Page::listable to automatically restrict the visibility of pages throughout the admin. I opened a request here: https://github.com/processwire/processwire-requests/issues/379 Besides Page::viewable, Page::editable and Page::listable there are also the following hookable methods that can be used in a similar way to the examples shown above. All of these methods are in PagePermissions.module. Page::publishable Page::deleteable (aka Page::deletable) Page::trashable Page::restorable Page::addable Page::moveable Page::sortable

Hi @adrian, Is it possible to use this javascript library on your module? https://jets.js.org/ I use it in my apps UI and it works wonderfully. This script filters in realtime all the elements of the page and shows only those related to the search query. @adrian If you want to do a quick test, you can install Tampermonkey extension in your browser and create a new script while you are on the Tracy Module config page. In that new script add the following lines: // @require https://cdnjs.cloudflare.com/ajax/libs/jets/0.14.1/jets.min.js then put the following code on the script part: (function() { 'use strict'; $("#ModuleEditForm").prepend('<input type="search" id="jetsSearch">'); // this line is only for testing var jets = new Jets({ searchTag: '#jetsSearch', contentTag: '.Inputfields' }); })(); Then save the script and reload the Module page, enter the parameter you want to access in the new input that appear on top of the page, ex: snippets, or scream, or suffix.. or any parameter you want to find PS: I use jquery to add the input field to the admin UI only for testing purposes, this search input element should be added by the module itself to the page rendering Please let me know if works on your end, here is working ok

Hi @Robin S and @szabesz - thanks for your input on this. This is going to be an interesting one because I actually don't like AOS's jumplinks for the reason that I can't use CTRL/CMD +F to find the setting I am looking for - I often have to enable/disable several sections before I find the one where the setting I am looking for is hiding. A tabbed interface would have the same issue. I feel like Tracy's approach to having everything open and displayed with those quick links (that are at the top of the settings) together with CTRL/CMD +F is actually pretty effective. There are also of course the direct settings links at the bottom of each debug bar panel which further helps to get you where you want to go. Of course this might be my bias because I already know the names of the settings so I know what to search for. With my thoughts out of the way, I have had enough comments over the years about how overwhelming the settings are that obviously I need to listen to you guys and improve things ? Robin - I have used tabs in module settings with AdminActions - I think it can be a nice interface, but in addition to my noted concerns above and your noted point about the tabs ending up over more than one line, some of the fieldset names (labels) are quite long - I can probably shorten many of these, but it is another issue to consider when using tabs. Stepping back a little - I wonder if we can solve some of the confusion by eliminating some settings - I have probably overdone things with settings that no-one will ever change. To be honest, I almost never change any settings beyond those in the first couple of fieldsets and the email address for error notifications on live sites. Maybe it would be best to have all the settings that are likely to be used by most people, open and up top and everything else in a collapsed "Advanced settings" fieldset. Maybe we need to do a bit of a survey to figure out what most users find themselves regularly changing and use that as a guide. On a side note, I often make use of https://processwire.com/modules/module-settings-import-export/ for copying settings between sites - maybe promoting that approach would also help? Any other approaches we should be thinking about? OT, but I am thinking that maybe this settings improvement feature request deserves to be split into its own thread. PS - Robin - I completely agree about the need to improve the styling of inactive tabs in th Uikit theme.

A little more to the back story... Client's biggest target audience is children's parties hence the look. The only time I said an absolute "NO" to client was when client said use "Comic Sans" font. There are some boundaries I will not overstep! Heading font is Google 'Happy Monkey'. ?

Macrura has developed module for this scenario (I think): https://processwire.com/talk/topic/6417-processwire-profields-table/?p=64275 The other thing - if you just want to make use of creating child pages with the PageTable interface, rather than actually use them in a PageTable field, check out: https://processwire.com/talk/topic/6102-batch-child-editor/?p=59733 The latest version's edit mode works very similarly to the PageTable edit mode - take a look at the screenshot for "3. Edit" in the first post. You can add new, sort, delete, quickly rename, and click to edit all fields in a modal popup.