Leaderboard

Hey folks! Took a couple of late nights, but managed to turn this old gist of mine into a proper module. The name is SearchEngine, and currently it provides support for indexing page contents (into a hidden textarea field created automatically), and also includes a helper feature ("Finder") for querying said contents. No fancy features like stemming here yet, but something along those lines might be added later if it seems useful (and if I find a decent implementation to integrate). Though the API and selector engine make it really easy to create site search pages, I pretty much always end up duplicating the same features from site to site. Also – since it takes a bit of extra time – it's tempting to skip over some accessibility related things, and leave features like text highlighting out. Overall I think it makes sense to bundle all that into a module, which can then be reused over and over again ? Note: markup generation is not yet built into the module, which is why the examples below use PageArray::render() method to produce a simple list of results. This will be added later on, as a part of the same module or a separate Markup module. There's also no fancy JS API or anything like that (yet). This is an early release, so be kind – I got the find feature working last night (or perhaps this morning), and some final tweaks and updates were made just an hour ago ? GitHub repository: https://github.com/teppokoivula/SearchEngine Modules directory: https://modules.processwire.com/modules/search-engine/ Demo: https://wireframe-framework.com/search/ Usage Install SearchEngine module. Note: the module will automatically create an index field install time, so be sure to define a custom field (via site config) before installation if you don't want it to be called "search_index". You can change the field name later as well, but you'll have to update the "index_field" option in site config or module settings (in Admin) after renaming it. Add the site search index field to templates you want to make searchable. Use selectors to query values in site search index. Note: you can use any operator for your selectors, you will likely find the '=' and '%=' operators most useful here. You can read more about selector operators from ProcessWire's documentation. Options By default the module will create a search index field called 'search_index' and store values from Page fields title, headline, summary, and body to said index field when a page is saved. You can modify this behaviour (field name and/or indexed page fields) either via the Module config screen in the PocessWire Admin, or by defining $config->SearchEngine array in your site config file or other applicable location: $config->SearchEngine = [ 'index_field' => 'search_index', 'indexed_fields' => [ 'title', 'headline', 'summary', 'body', ], 'prefixes' => [ 'link' => 'link:', ], 'find_args' => [ 'limit' => 25, 'sort' => 'sort', 'operator' => '%=', 'query_param' => null, 'selector_extra' => '', ], ]; You can access the search index field just like any other ProcessWire field with selectors: if ($q = $sanitizer->selectorValue($input->get->q)) { $results = $pages->find('search_index%=' . $query_string . ', limit=25'); echo $results->render(); echo $results->renderPager(); } Alternatively you can delegate the find operation to the SearchEngine module: $query = $modules->get('SearchEngine')->find($input->get->q); echo $query->resultsString; // alias for $query->results->render() echo $query->pager; // alias for $query->results->renderPager() Requirements ProcessWire >= 3.0.112 PHP >= 7.1.0 Note: later versions of the module may require Composer, or alternatively some additional features may require installing via Composer. This is still under consideration – so far there's nothing here that would really depend on it, but advanced features like stemming most likely would. Installing It's the usual thing: download or clone the SearchEngine directory into your /site/modules/ directory and install via Admin. Alternatively you can install SearchEngine with Composer by executing composer require teppokoivula/search-engine in your site directory.

I couldn’t resist the hype and created a simple module using the ChatGPT API to process field values. You can find it on GitHub here: https://github.com/robertweiss/ProcessChatGPT ProcessChatGPT is triggered upon saving, if you select it in the save dropdown. It processes the value of a page field, which can be set in the module config, using ChatGPT. The processed value can be saved back to the same field or to another field on the same page, which can also be set in the module configuration. You can add commands to the value that will be prefixed to the source field content. This way, you can give ChatGPT hints on what to do with the text. For example, you could add ›Write a summary with a maximum of 400 characters of the following text:‹. One of my clients is already using the module to summarise announcement texts for upcoming music events on their website (Let’s face it, nobody reads them anyway ?). If anyone finds it useful, I would be happy to submit it to the official module list.

Hi @DV-JF Probably you can use 1 option and then make a hook to 'ProcessPageView::pageNotFound' and within the hook, definition make a redirect to the login page like $this->wire()->pages('/login/')->url([ 'language' => $this->wire()->user->language, ])

The other thing that I think should be implemented is a better cache expiry option - given how infrequently sitemap.xml files are called by search engines, I don't really think any sort of time based expiry is much use in reality. I think it should support wireCache's selector option (set to expire when any page is saved - although on regularly updated sites, even this might not result in the cache being used very often).

Hi @Mike Rockett I just discovered that the sitemap is always generated, no matter what cache settings. In https://github.com/mikerockett/markup-sitemap/blob/2db851e9bc3e7147879dced1bcfe515cd86562a8/MarkupSitemap.module.php#L269 the generation is done before checking for cache and returning cached output. I amended the method to read protected function getSitemap(string $rootPage): string { // Bail out early if debug mode is enabled, or if the // cache rules require a fresh Sitemap for this request. if ($this->requiresFreshSitemap()) { $sitemap = $this->buildNewSitemap($rootPage); return $sitemap; } // Cache settings $cacheTtl = $this->cache_ttl ?: 3600; $cacheKey = 'MarkupSitemap'; $cacheMethod = $this->cache_method ?: 'MarkupCache'; // Attempt to fetch sitemap from cache $cache = $cacheMethod == 'WireCache' ? $this->cache : $this->modules->MarkupCache; $output = $cache->get($cacheKey, $cacheTtl); // If output is empty, generate and cache new sitemap if (empty($output)) { header('X-Cached-Sitemap: no, next-request'); $sitemap = $this->buildNewSitemap($rootPage); $output = $sitemap; if ($cacheMethod == 'WireCache') { $cache->save($cacheKey, $output, $cacheTtl); } else { $cache->save($output); } return $output; } header('X-Cached-Sitemap: yes'); return $output; } This seems to be working fine.

We've got just a few core updates on the dev branch this week, but next week we're looking at finally merging in the InputfieldTinyMCE module! This week I also wrapped up the WireRequestBlocker module that was mentioned in last week post, and the v1 beta is now posted in the ProDevTools download thread. I've been running it here on processwire.com this week and it's been doing a good job of keeping out the vulnerability scanners and bots. For more details on this new module please see the new Wire Request Blocker page that I just posted. Thanks and have a great weekend!

Hey @ryan sounds like a great module ? Wouldn't it be nice if the module's config screen showed that information? So it would be in a safe space without additional steps to do ?

Question: is processwire better than wordpress? Answer: