Leaderboard

This module allows you to integrate hCaptcha bot / spam protection into ProcessWire forms. hCaptcha is a great alternative to Google ReCaptcha, especially if you are in the EU and need to comply with privacy regulations. The development of this module is sponsored by schwarzdesign. The module is built as an Inputfield, allowing you to integrate it into any ProcessWire form you want. It's primarily intended for frontend forms and can be added to Form Builder forms for automatic spam protection. There's a step-by-step guide for adding the hCaptcha widget to Form Builder forms in the README, as well as instructions for API usage. Features Inputfield that displays an hCaptcha widget in ProcessWire forms. The inputfield verifies the hCaptcha response upon submission, and adds a field error if it is invalid. All hCaptcha configuration options for the widget (theme, display size etc) can be changed through the inputfield configuration, as well as programmatically. hCaptcha script options can be changed through a hook. Error messages can be translated through ProcessWire's site translations. hCaptcha secret keys and site-keys can be set for each individual inputfield or globally in your config.php. Error codes and failures are logged to help you find configuration errors. Please check the README for setup instructions. Links Github Repository and documentation InputfieldHCaptcha in the module directory Screenshots (configuration) Screenshots (hCaptcha widget)

I do it like this:

You can also configure your CKEditor field to insert <br> tags instead of <p> tags on Enter. https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR.html#property-ENTER_BR

Likely irrelevant, but... // wire('pages') $existing = wire('pages')->get("template=supplier, unique_id={$record['Unique ID']}", ['cache' => false]); ... // $pages $pages->uncacheAll(); I don't see anything obviously "wrong" with your script, which is why I'm wondering if it could be possible that this uncache call isn't doing what it should?

// not tested class TextformatterP2BR extends Textformatter { public static function getModuleInfo() { return [ 'title' => 'P2BR', 'version' => '1.0.0', 'summary' => 'Textformatter that strips all <p> and replaces </p> by <br>', ]; } public function format(&$str) { $str = str_replace("<p>", "", $str); $str = str_replace("</p>", "<br>", $str); } }

Hello, I use this the Menu builder module. Easy and works very well. I'm also using bulma and was able to it without problem.

Change Default Language to be None-English | Walk Trough When you start a new (single) language site and the default language shouldn't be English, you can change it this way: Go to the modules core section: Select the Language ones by the filter function: We have four language related modules here, but for a single language site in none english, we only need the base module, named "Languages Support". So go on and install it. After that, you can leave it, ... ... and switch to the newly created Language section under SETUP: Select the default language Enter your new language name or its Shortcut and save the page. I will use DE for a single language site in german here as example: Now I go to the ProcessWire online modules directory, down to the subsection for language packs and select and download my desired (german) one: After downloading a lang pack as ZIP, I go back into my SETUP > LANGUAGES > default language page in admin, select the downloaded lang pack ZIP and install it: After the ZIP is uploaded, the files are extracted and installed, most of my screen is already in the new default language. To get all fully switched, we save and leave that page, ... ... and completely logout from the admin. Now, of course, we directly login back, ... ... and see, that now also the cached parts of the admin have switched to the new default language. ? That was it for a single language site in none english. If you want to have a multi language site, just add more languages to the SETUP > LANGUAGES section. When using a multi language site, I think you also want to use multi language input fields, and maybe different page names for your language page pendents. If so, you need to go into MODULES > CORE > filter LANGUAGE and install what you need or want to use of it, (if not already done). Thanks for reading and happy coding, ?

For anyone stumbling on this old thread, it looks as though Ryan has now addressed this issue (though I have yet to have a chance to test it):

Thanks @horst for this tutorial, which is very good for new users. I also updated the link in the README of the german language pack: https://github.com/jmartsch/pw-lang-de/blob/master/README.md

No idea then, in that case, sorry ?

Sorry, of course you get the ids! ? But you can already be enough depending on your situation. Do you dump lots of data? Or is in-memory an option? What does that mean? How do you know? How does a tracy dump look? Did you follow the docs? https://github.com/baumrock/rockfinder3#relations Did you already read about callbacks? https://github.com/baumrock/rockfinder3#callbacks

There were lots of core updates this week, very much in the same theme as last week — major long term quality improvements for the core, but no shiny toys to play with… Just lots of good and solid foundational core improvements, and a few fixes too. It's mostly kind of technical stuff that's probably not that interesting to read about, so I'll keep this short, but for those interested here's the commit log. Thanks for reading and have a great weekend!

So far only seen the site on mobile, but at least from that point of view it looks and feels really good. Especially enjoyed the typography. Great job! Can't wait to get a closer look on desktop ? (The pause/play button on the home page carousel is a nice touch, by the way.)

I realise that this is a rather old request, but I've just added a config setting for this. It's available as of AdminBar 2.5.0 ? So far I've been unable to reproduce this issue. There's a check for RepeaterPage, in which case it should be skipped for this sort of purpose, and since RepeaterMatrixPage extends RepeaterPage that should kick in here as well. Please let me know if this still occurs, though, and I'll be happy to take a closer look!

Handle yourself (in code) or use the whitelist option, in which case ProcessWire will handle them automagically for you — but anyway, whitelist is also explained on that page ?

You need to handle 404 errors yourself. Look here for a working example.

Right, forgot that one! It's fixed now in the latest release.

Thanks @Mikie! I'll definitely look into the table part. There's no built-in way to get the entire index at the moment, but it might make sense to have one -- though what you're doing sounds like a perfectly good way to solve this for the time being. Anyway, I'll look into this as well. Just for the record, the renderResultsJSON method was added primarily to solve client side search needs (but I'm guessing that's not exactly what you're after) ?

If you're using the code you posted earlier, i.e. "$results = $pages->find(...)" and "$out.= $results->renderPager()", SearchEngine settings won't kick in at all. This is plain old native ProcessWire stuff, so you'd have to provide pager settings directly to the renderPager() method ? SearchEngine pager_args only apply if you're using it's native rendering features. Though please let me know if I'm missing the point here!

This is on the top of my to-do list now ?

Hey Bernhard! SearchEngine already provides a way to highlight hits found from the generated summary, but since there's currently no built-in way to show dynamic summaries on the search page, this doesn't apply to the entire index. See here for an example: https://wireframe-framework.com/search/?q=wireframe. Please let me know if I've completely misunderstood what markjs does – I'm interested, but not quite sure if it would be beneficial, and/or how it would differ from current situation ?

Sorry for the late reply. This is definitely something I'll have to figure out, one way or another, just haven't had the time (or need for that matter) yet. I'll have to do some testing first and get back to this later ?

Couple of updates during the past week, 0.11.0 and 0.11.1. I'll attach the changelog below, but here's a summary of changes: Saving just a single field (via API or perhaps some async feature) should now correctly regenerate the search index. Page Reference fields are supported: the title and name values of referenced pages are stored in the index. Page names can also be search with the field name; if, say, you have a Page Reference field called "tags", you can find specific matches by searching for "tags:[tag-name]" ("tags:tailwind" etc.) One relatively big change behind the scenes is that now the search index is generated after page has been saved, by hooking into Pages::savedPageOrField and triggering a new save for just the index field, quietly and with hooks disabled. Originally the module hooked into Pages::saveReady and generated the index so that it got saved along with any user-provided changes, but it turns out that this could result in some rather obscure bugs due to output formatting being enabled on the fly (which is intentional, and required for the most representative search index) which in turn was triggering interesting side effects under some specific conditions. So far the new method hasn't resulted in any unexpected side effects as far as I can tell, but it's worth pointing out this is a pretty big update. ## [0.11.1] - 2019-09-26 ### Changed - Index value gets saved in Pages::savedPageOrField instead of Pages::saved. ## [0.11.0] - 2019-09-26 ### Added - Support for indexing Page Reference fields. - Support for indexing non-field Page properties (id, name). - New hookable method Indexer::___getPageReferenceIndexValue(). ### Changed - Index value gets saved in Pages::saved instead of Pages::saveReady so that we can avoid messing with the regular save process. ### Fixed - Fixed the "save" behaviour of the Indexer::indexPage() method.

Assuming that I correctly understood your need, this would require dynamically generating the descriptions. Technically it should be doable by hooking into Renderer::RenderResultDesc(), but you'd have to provide the entire description generation and highlighting logic yourself, so it might be a bit difficult to achieve in practice. This is actually something that I've got planned, but I'm not really sure when I'll get to it. Anyway, it's good to know that there's demand for it.

Good morning! AdminBar 2.3.0 was just released. Here's the changelog for this version: ## [2.3.0] - 2019-08-29 ### Added - Gravatar image support for the "user" item in Admin Bar. - Support for sorting Admin Bar items manually with the AsmSelect field in module config. - A changelog file. ### Changed - Protect logout link from accidental clicks (script or otherwise) by converting simple link to a logout form. - When modal window is opened, hide children and view tabs with CSS first in order to prevent flashing content. Due to the manual sorting feature mentioned above there was a change in the data structure, so note that if you're already running AdminBar and have modified the visible items in the bar, you'll need to reconfigure those. This was the easiest way I could figure out to achieve free sorting feature: Minor note: currently it's possible to add the same item to both left and right columns. I didn't see a reason to specifically prevent this, so it's kind of a feature – though not sure if that's something you should ever do from a UI/UX perspective ?

You're correct that AdminBar only applies to users who are logged in. There's no "guest user" when it comes to AdminBar – only superusers and users with the "adminbar" permission will see anything out of the ordinary. Regardless, since AdminBar outputs features visible on the front-end, it's very much connected with everything else happening there. What you're missing here is that being logged in won't disable those browser extensions or nullify the effects of third party libraries – so it's not true that those features would only apply to users who aren't logged in. As such, it's very important that admin bar is as "tolerant" as possible, so that it won't break or cause new problems if you decide to implement a new JavaScript library on your site (or enable a browser feature/plugin).

You're right that browse isn't really a link – that's definitely one that shouldn't be represented by <a> tag ? Logout is a border case: technically it can be a link, just like it is right now, but you're right that it probably shouldn't be. On the other hand even changing it to a form isn't, in my opinion, quite enough – it should also provide and validate some sort of nonce/token, just to be sure that it can't be abused. There's no redirect after logout at the moment either, so that's not a major problem. Anyway, I'll figure something out for the next minor release of the module. Create is one of the cases where a link usually makes sense: it should be a link to the "new page" view in Admin in case the modal mode is disabled or JavaScript is for whatever reason out of equation. That being said, I've almost never used the "name format" option, so I didn't even think of that – that behaviour is indeed problematic and needs to be addressed somehow ? It just occurred to me that my earlier explanation was flawed ? If you reload, say, just the <main> element within your <body>, and Admin Bar remains as-is, the links/buttons there will point to the wrong page. As such using such plugins you probably would need to reload Admin Bar as well. I could add support for modifying target/parent IDs with JavaScript, but that would still require extra steps for the developer anyway. Also thought about using URL in this case, but that wouldn't help, as Admin Bar can't know for sure if you're using "real" URLs or some custom format (via URL segments, History API, or something else.) Currently I'm thinking that an option for reloading / re-rendering Admin Bar via JavaScript might actually be the best option here: in most situations the module would work right out-of-the-box, but if you do use some sort of front-end routing / transition code, you could somehow tell it to update. Not a perfect solution, so any suggestions are welcome. -- By the way, if – and only if – it turns out that one/some links can't be easily switched to buttons without sacrificing something else, do you know if role="button" would help at all? I wouldn't use that unless I really have to (reinventing <button> with ARIA attributes is almost always just plain dumb), but this might be one of those cases where it's actually the most sensible approach – it would be an improvement in terms of accessibility, but I've no idea if it would help with preload/prefetch/etc. features ?

Thanks for the feedback! Replacing <a> tags with buttons was originally on my list, but I've been pushing it back as there are some additional considerations here: There are some "proper links" (such as the admin link) that should remain that way. As such, this wouldn't apply to all links automatically. When the modal ("slide overlay" in module settings) mode is disabled, almost every item should be a regular link – except for browse, which technically shouldn't do anything there, as in that case it's just an indicator of your "current state". Admin Bar should work regardless of JavaScript. This makes it more robust, and as such more accessible. That last point isn't an argument against using buttons, just something to keep in mind when making changes: everything should remain functional regardless, which could mean links by default (when JS isn't available, or working as expected) and buttons otherwise. Since default styling is now based on BEM, it should make this easier in some respects, though; technically what element is used shouldn't matter anyway. I don't actually see (m)any notable issues in the current behaviour. None of the built-in Admin Bar features will create any content without user actually submitting a form – and I'd be very surprised if a plugin did that on itself. The logout link is problematic though, you're absolutely right on that one – I've added this on my todo list, but not entirely sure yet how to handle it. I'm not familiar with Turbolinks, but the way Barba.js usually works is that you define a container, which you then switch with new content. I'm not particularly experienced in this regard, but to my best understanding you wouldn't usually define your entire <body> element as a container, and since AdminBar attempts to place itself as the last element right before </body> closing tag, normally this shouldn't be an issue – though again, this is just based on my (quite likely lacking) understanding of such libraries ?

Thanks – this should now be fixed in the latest version (2.2.2).

Could you clarify this a bit, what kind of mistake are you seeing? So far I haven't noticed anything wrong here, so it might be browser-dependent, or perhaps even site-dependent (Admin Bar is affected by site styles as well, so there's always a chance for that). Please let me know what browser you're using, how it behaves – and if possible, a screenshot would be really helpful too ? You mean when you add items via config settings? The order there doesn't actually affect the order of items in the Admin Bar – at least yet. That's something I have on my todo list, but not sure yet when I'll get to it ?

Thanks – this is now included with the latest release, 2.2.1 ? I made a couple of minor adjustments: in mobile size the dropdown was positioned slightly too far down so there was a gap between the icon in the bar and the dropdown, and the "ul li > a, ul li > strong" CSS rule was changed to ".adminbar__link" in order to avoid unintentionally affecting unrelated lists on the site. I'll have to think about this a bit, not sure yet how it would fit the module. Technically this could be a relatively simple modification: the dropdown feature used for the "user" item applies to any item that has a "children" array, so one option would be adding that for the edit link. Haven't tested this yet, so not entirely sure, but that's one option at least ?

Just checking that I got this right: do you mean that while the "slide overlay" is enabled and Admin Bar links (such as edit, new, and profile) will normally open the edit view in a "modal" window, there would be some way to open the target URL without the modal instead – going to the "full" admin interface? ? If so, I can see value in this idea, but I'm not yet sure how to make that happen without messing up the simplicity of the UI or causing potentially confusing side-effects. Take long-click for an example: in my experience it's actually quite common for users to long-click or double-click things by accident (or by habit), so in my opinion (in a web based GUI) it's usually bad UX for these to lead to a different outcome vs. "regular click". Anyway, I'd be interested in implementing this if there's a way to do it in a sensible way. And please let me know if I've misunderstood your idea ?

Hey folks! Just released AdminBar 2.2.0. Here's what's new: New module config settings for selecting items displayed in the Admin Bar. New items, disabled/hidden by default: "profile" (simple profile edit link) and "user" (basically the same concept as the profile edit dropdown menu in Admin). If "user" is displayed, there's a config setting for items displayed under it as well. New hookable method ___getData(). The returned array is converted to an object and stored as JSON (data-adminbar) on the Admin Bar element. This was mainly added for future JS features, but can be used by themes etc. as well. Hookable methods and their primary purposes are now also documented in the README.md file. Quite a bit of code was rewritten – again. I've been splitting some methods to smaller ones to improve maintainability, fixing small issues, improving accessibility to some degree (still needs a lot of work though), etc. Hopefully didn't cause too many new problems in the process... ? Here's a screenshot with new items enabled, though one probably wouldn't want to enable profile and user (and all the user dropdown items) at the same time – and yes, my user name on this site is "admin", so it looks a bit silly when there's an "admin" link before and below it as well ? --- Thanks! This will be the next item on my list ?

Thanks for pointing these out. Latest release (2.1.0) includes improvements to spacings and the position of the triangle. Just for the record, the positioning is of the triangle was actually intended to be consistent with Admin Theme Uikit, where it's also off-centre, but I've now centered it in Admin Bar anyway ? In 2.1.0 the problem with "add new" button has been fixed. My initial idea was indeed to leave these buttons out if they have no purpose, but opted to leave them as-is, because that's how it's always been. For the same reason I was slightly hesitant to remove the full stop: this change will break existing translations. I've now done it anyway, since it's a relatively small thing. Note that 2.1.0 is actually bigger update than I anticipated. Class names have changed a bit, all themes had to be updated slightly, there's new JS, layout is now based on flexbox instead of floats, etc. So far things seem to work as expected (better than before), but let me know if there are any new issues ?

Yeah, this should be an easy one. You can hook before or after AdminBar::getItems: either modify $args['strings'] before it gets passed to the method, or modify the resulting array of items before it is put to use ? Makes sense. I would definitely take a route that affects actual permissions. Since AdminBar checks Page::editable() before displaying the edit link, if this was done using permissions, I believe it should just work out of the box, i.e. the edit link shouldn't display at all ?

Thanks, @adrian. I've been using this module for a long time, and it has actually been quite fun to work on it ? A profile edit button seems like a good idea. That was on my list for a while actually, but I wanted to get 2.x out sooner rather than later, so had to leave that for a later release ? I think we'll also need a "select enabled links/features" option to avoid too much clutter. On many (most) of the sites I've built this feature, for an example, profile edit feature wouldn't have been particularly useful – users often edit their profiles really, really rarely – so I'd like to leave it to superusers to figure out which features are necessary. (Could also make the feature selection configurable per user, if there's demand for such a feature.) Restricting editable pages to ones the user has created seems to me like a relatively specific need – at least I haven't personally come across a project where this would've been particularly useful. As such, my initial view is that this might be best implemented as a per-site customisation. Unless, of course, I'm wrong and it's actually a commonly needed feature, in which case it may make sense to add a setting for it ? Note that one key point about the hooks I've added is that it's now quite easy to customise what is displayed in the Admin Bar, and how. One example of this is what I've done with the "Uikit" theme, where I've added icons to existing items, and also the PW logo/mark as a new item. If you hook into AdminBar::getItems, you can easily modify the list, and – for an example – only show the edit link under specific circumstances. (And if this is a feature you require often, you can always bundle this, and any other modifications, into a separate module.) By the way, I'm assuming that this would actually be just about displaying the edit link – not modifying permissions? Modifying permissions would, in my opinion, definitely belong to another module. As far as I can tell, this item has been "Browse" since the beginning – at least for the past 8 years or so, according to GitHub ? I'm slightly hesitant to change what I consider established terminology. Also, I don't personally see the problem: technically what this item being active means is that you're currently browsing the site. Kind of like "browse mode" vs. "edit mode". When you're in admin and want to view a specific page, "view" is indeed better word, but in this context I actually prefer "browse". Again it's quite simple to modify this with a hook, of course, but I think I'd rather stick with current terminology for the default state.

It's great to see new life breathed into this module - thanks @teppo. Two things I added to one installation of mine was the ability to edit the user's profile and the other was to restrict them to only be able to edit pages that they have created. Would you consider adding those features? One other thought - I am a bit confused by "browse" vs the old "view" - browse to me suggests browsing through multiple pages, rather than viewing the current one which is what this link does. What do you think?

AdminBar 2.0.1 released: Plenty of updates behind the scenes. So far "end user" functionality remains largely the same, though. New options for hooking – decent support for modifying generated output and adding all-new links and other features programmatically. Extended theming support: the module now comes with three built-in themes ("original", "tires" per the theme submitted earlier by @tires, and "uikit"). Uikit is an adapted version of the top bar in admin, and it's now the default theme for the module. Each theme may include its own settings (Uikit, for an example, allows displaying/hiding some or all of its icons and the ProcessWire mark). Custom theme support is still there, but requires a few modifications: custom theme needs to be selected via module config screen, you need to provide a directory where theme files live, and this directory has to contain (at least) a theme.css file (but optionally also theme.js for custom JS, theme.php for hooks, and config.php for custom module config settings). Oh, and the module is installable via Composer now – just run "composer require teppokoivula/admin-bar" in your sites root directory, or the /site/ directory. New requirements for 2.0.1 are ProcessWire >= 3.0.112 and PHP >= 7.1.0. For earlier version of ProcessWire or PHP, use release 1.1.5 (this version won't be updated anymore, but should work in ancient version of PW and PHP). Below is a screenshot of the "Uikit" theme in action on the Wireframe website. In this case I've disabled the icons from the left side of the Admin Bar – by default each action there would have its own icon as well.

Added a note about new maintainer to the top of the first post, and updated the "grab the code" link. Might make some sense to rewrite the first post altogether, but the forum doesn't (as far as I know) allow replacing it, so creating a new support thread might make sense as well ?

Some updates for AdminBar in the latest release (1.1.0): Got rid of the jQuery dependency. Not a big deal, but that's still one setting and one dependency less. As a result the module probably won't work as expected in IE < 11, so if someone is still stuck with ancient browsers, it's better to stay with version 1.0.7 (tagged in the GitHub repository). Some minor optimisations and tweaks here and there. Nothing major, really. Just tested @tiress styles, and they seem to still work as expected, so most custom themes are likely unaffected ? For the record, I'm thinking of releasing a 2.0.0 of this module pretty soon. This would be a breaking change, and require ProcessWire 3.x, PHP 7.x, etc. I'm also thinking of moving custom styles out of the module directory so that the whole directory can be safely removed during updates.

Great to hear that it works now. The problem with automating this is that I don't want to assume which templates should become searchable. That being said, I could add an install-time setting to pick templates to add this field to, or alternatively a module config setting that fetches this info real-time from templates. I think that'd be a pretty nice solution overall, so I've added that to my to-do list. There was – it just wasn't working quite as expected ? I hadn't tested this properly: translatable strings were defined and cached too early during the module's bootup sequence, with the result that the language of the user wasn't actually set yet, and thus you always ended up with the default (english) versions. This should be fixed in the latest release, 0.6.2. There's a basic demo here with most public-facing search-related terms translated: https://wireframe-framework.com/haku/. Sorry for the inconvenience, and thanks for digging out these issues!

Hey @VeiJari, thanks for your report ? Those warnings were fixed in version 0.5.1 – I keep forgetting that core classes don't use strong typing for non-object parameter values. Lesson learned: always develop with debug mode on (or use something else to display all warnings). "Indexed 0 pages in 0 seconds" isn't related to the warnings. This just means that the module couldn't find pages with your configured search index field. I've added a warning message for this situation, explaining what happened and what to check first (that your index field is actually added to at least one template with existing pages), but other than that I'd have to know a bit more about your specific setup to answer why this is happening. Additionally (with latest release 0.6.0) I've changed the defaults so that any non-trashed page with the index field is now automatically included. Previously the default selector for this feature only included public pages, which meant that hidden and/or unpublished pages were not indexed (via the "Index pages now?" feature, that is – saving the page itself indexed it as expected). -- If you're still getting a message that indexable pages couldn't be found, please let me know how you've configured the module, and which version of ProcessWire you're using. Also please make sure that you actually have indexable pages to begin with – unless you've specified a selector string for the "Index pages now?" feature, this is the selector that finds those pages for you ?

I think trasferring it to me would be best, whatever this means in practice ? I'd rather keep the current name if it's an option. No need to confuse folks by new forks.

That'd be fine with me. To be honest I've been meaning to fork it (under a new name) and take the concept a bit further – mostly visual / UI stuff, really ? If you edit the modules directory entry you can change URLs and the "forum name of the author". Might be enough in the short term? Anything other than that probably requires help from Ryan. I haven't been using this module much on my own projects either. For client sites I've been in the habit of always setting it up, though the modal / dropdown editing thingy is usually disabled. Basically it's just a simple way to provide necessary edit/add/profile/logout links (which should be there in the front-end anyway). Sure, I could add those links to some template file, but why bother when there's already a module for that ?

One last update for the day: master branch of the module is now at 0.5.0. This includes both the rendering features mentioned above, and a slightly more polished theming feature, where each theme can declare custom markup, styles, scripts, strings, etc. More details in the README file.

It's true that this is a bit tedious – to say the least ? The indexer doesn't currently have stemming support or anything like that built-in, which means that it can only find exact matches. I'd love to include something more elegant, but I'd first need to find a solution that works reliably across multiple languages – at least German, Swedish, Finnish, and English, since those are the ones I personally need most, and that would probably cover a large part of the audience here. If such a feature does get added, it might also make sense to distribute it as a separate module (which wouldn't be particularly hard, really). By default the module uses "%=" selector, which I've personally preferred over "*=".This is partly because I actually want partial matches, but also because back in the days the "*=" selector didn't seem to work too well with Finnish content. This way I'm not constantly worrying about MySQL quirks, full-text stopwords, etc. Anyhow – I just experimented by changing the selector operator to "*=", and now the only hit is the "Why use Wireframe?" page, which has the word "battle-tested" on it. Default selector is configurable via site config, or you can pass custom selector in if you query results yourself, and that might actually be enough to resolve some issues already. Currently there are a lot of options that are only configurable via site config (code), but I'll probably add these (selectively) to the admin as well. It's just a lot easier to add them in code first ? (Edit: on a second thought I'm probably going to switch the default selector to "*=". Seems like it will be better for most users, and those who don't like it can always change it.) Finally, the description text shown on the search results page is pretty "dumb", currently defaulting to the value of the summary field. Obviously that won't do for sites that don't have this field, but it's there for most default profiles, so that seemed like a reasonable starting point. In my own projects I'd probably make that "meta_description|summary", since those fields will always be there, and they are pretty much exactly what a view like this needs. I'd love to create the summary from the index so that it can always (or nearly always at least) show a piece of text that matched (kind of like Google does), but since the index is essentially a whole lot of mismatched text stuck together, that would often look pretty awful. Google does these "custom excerpts" well – obviously – but even Relevanssi (which is the de facto search plugin for WP) struggles with this part and in many projects produces unreadable mess when the custom excerpt option is enabled. (Mainly because such a feature is a nightmare from a logical sense.) Awesome! ?

Another quick update: rendered search feature is now visible at https://wireframe-framework.com/search/. Entire content area (between main menu and the footer) is rendered by the SearchEngine module. The rendered version (if bundled styles are used, which is optional) should look more or less like that on most sites – obviously site styles come into play, so it may be a bit off and require tweaking, but that's to be expected ? Pager is now included as well, but on this site you'd have to search for something silly like "co" to see it in action. The default limit is set to 20 results, and the site doesn't have that many pages to begin with. The styles are organised into "themes", which currently means any number of custom CSS and/or JS files, but I'll probably expand these to include custom config files as well sometime soon. This way it should be easy to create multiple built-in themes to select from (for different frameworks or whatever). The render feature is currently only available via the dev branch of the module. I'll test it a bit more before merging to master – probably tomorrow ?‍♂️

The way markup generation is currently implemented can be seen in the dev branch at the GitHub repository – it's pretty easy to grasp by taking a look at the render settings in the SearchEngine.module.php file: https://github.com/teppokoivula/SearchEngine/blob/dev/SearchEngine.module.php#L70:L124. Instead of defining big chunks of markup in one go, I've tried to make the rendering "atomic" enough to allow for pretty much any kind of modification. Technically a framework-specific version could mean just alternative 'classes' and 'templates' arrays, and of course whatever custom styles might be needed. Not sure if I got your point right, though, so please let me know if this seems very different to what you were thinking ?

Quick update on this module: got a bunch of rendering features almost ready to ship. Still need to add paging support and may add a "fast mode" that always returns default markup (not sure how important that would really be, it's just an idea I've been tinkering with), but that's just about it. I'll probably bundle the (optional) styles – and later scripts – with the module, just to provide a decent-looking default state right out of the box (for actual use or testing). Also, I'm thinking of adding a "load more" alternative to paging, but that'll probably be a later addition. Somewhat off-topic, but I've been going back and forth with BEM: sometimes I love it, but often it just complicates things and makes both CSS and markup hard to maintain. Nevertheless, in a project like this it's just brilliant! By declaring search form, results list, and a single result as separate components, I can quite easily style them individually, not worry too much about messing with site markup in general, and it's also really easy to override just s specific part of the default styles in site-specific styles. Anyway, currently the ("full", i.e. a form and a results list) rendered state looks like this:

Each indexed field should be declared (named) in the config setting mentioned above, or via the "Indexed fields" AsmSelect field in module config. If you have a lot of fields to add, this may of course take a while, but generally unless you have a whole lot of fields it shouldn't be a major issue. Also, SearchEngine doesn't (currently) distinguish between Repeater / PageTable / RepeaterMatrix content: if they contain indexable fields, the values from those fields are indexed as part of the parent page's search index. Though now that I've said that last point out loud, I think that content from repeatable fields should only ever be included in the (parent page's) index if those fields are set to be indexable as well. I'm going to make this change in the next release ? Edit: done now (0.3.2). Repeatable fields need to be included in the indexed_fields array before their values can be stored in the index. This is really how it should've been from the start. -- Note that if you use the config setting instead of module settings for "indexable_fields", it's possible to generate that list of fields programmatically. I.e. you can define some hard-coded field names, and then merge that array with another one you generate with code. I'm not sure how efficient that would be, but it's doable at least. Additionally there are various hookable methods in the Indexer class included with SearchEngine, so if you need something more specific, you can always hook into those and change what gets indexed.