Leaderboard

The module seems stable enough to bump to version 1.0. Notable changes Declare a private namespace, solving install issues Require the latest ProcessWire master version 3.0.165 Add a new panel type Add New Page which recreates the core add-page shortcut menu

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.

Hello @ all ! Today I want to share another new inputfield with the community! It is called Fieldtype OpeningHours and it is designed to enter one or multiple times per day (especially for company opening times). I know that there is another great fieldtype in the repository (https://modules.processwire.com/modules/fieldtype-business-hours/), but I wanted to create my own with a different UI than the other one. Here is a screencast of what it looks like in action: OpeningHours.mp4 A lot of things going on behind the scenes and I dont want to write it all down here, because you can find the whole information on my Github account. https://github.com/juergenweb/FieldtypeOpeningHours Requirements: PHP >= 8.0 (because it uses union types, I have also tested it with new PHP 8.2) ProcessWire >=3.0.181 If you may find any bugs, have any ideas to improve this fieldtype please report it in my Github repository. Greetings from Austria and have a nice day! CHANGELOG: 21.7.20 Add new option to show (true) or hide (false) days with no opening hours on various methods (please be aware that setting options has been changed - it is recommended to deinstall old version and install this inputfield again) . Take a look at the READ.ME for further instructions. 1.1 Add multilang support for timeformat and add 2 additional Schema.org markup methods UPDATE: 09-06-2023: The module has been added to the module directory and can be downloaded from there after it has been published.

Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

I'm not sure I fully understand what you're trying to achieve here, but no — this is not something SearchEngine does. It creates a single index for the entire site. I have considered adding support for multiple indexes, but a solid need for that never surfaced. Would be interesting to hear if there's one now, though admittedly this seems more like a need for a custom search engine, and thus likely has little to do with this module. The TL;DR seems to be that "this is not the module you're looking for", but I'll go through your questions just to clarify things: I'm not entirely sure what you mean by adding custom operators. If you're referring to selecting some operator that isn't available via SearchEngine settings, that's possible, but to be honest most of the selectors that make sense within site search queries are already there. As always it's good to read the docs, though; understanding selectors and selector operators is a key factor when working with ProcessWire ? Anyway, the settings you see in this screen are defaults. Most site search tools don't let visitors select operators or even alter the sort order in any way, so setting them once here is enough. If you're working on something more complex — perhaps something like library databases often provide — these settings have little to do with that. In this case you're probably not going to have much use for SearchEngine, although it's of course possible to create a custom search feature and use the search_index field as a regular field in your queries. At the moment you can't. These are not fields, they are indeed (literal) table columns. Search Engine doesn't work on that level. It'd be possible to add this feature, but at the moment this seems like an extremely rare need, and as such it's not particularly high priority. The selector inputfield you see when you use "Index pages now" feature is only a tool for finding the pages you want to index, and it's using the core Inputfield Selector for selecting applicable pages. The first part is not really in the scope of SearchEngine: it's a tool for providing a site search, and since sites consist of pages, that's what it will list. It does indeed sound like you're looking for something more customized. ... although you can in fact a) completely skip any front-end markup generated by SearchEngine and provide your own instead (basically just use the search_index as a regular field in queries), or b) modify markup generated by SearchEngine using hooks, or even c) hook into the indexing process to fill in other custom fields in addition to the default search_index field. All of these would require plenty of custom work, and I'm honestly not sure if you'd find SearchEngine useful for your needs; you may find it easier to build the entire thing from scratch.

Here is a script I made for the import of thousands of customers. You have to save this as shell script (f. e. sync-customers.php.sh), make the script executable and execute it via command line (./sync-customers.php.sh).

Cloudflare announced the general availability of their new Web Analytics solution today (even for non-Cloudflare-powered sites): https://blog.cloudflare.com/privacy-first-web-analytics/ I'm quite excited about this, as I've been looking for a solution that's both privacy-friendly, free for personal sites and GDPR compliance. In particular, being able to collect visitor statistics without tracking any personal data is an attractive proposition, since it doesn't require consent even under the GDRP. I looked at various alternatives, but all have their caveats: Google Analytics is out for obvious reasons. Matomo is a solid choice since it can be configured to not set any cookies and anonymize IP addresses. However, it's use of fingerprinting is somewhat dubious, so it's a grey area whether you need consent to use it. A couple smaller alternatives like Netlify Analytics (for Netlify sites) or fathom look good enough, but their pricing isn't really feasible for small personal projects. I have added the Cloudflare tracking script to my tutorial site processwire.dev, for now I'll use it alongside Matomo. Will be interesting to see how their numbers compare to Matomo. What do you all think? Are there better alternatives out there?

According to the bureau of the Datenschutzbeauftragte of NRW, germany: If you (self)host Matomo on the same domain or subdomain with anonymized IPs, you can start to use it without opt-in, regardless if cookie-less or a use with cookies. Only thing you must provide and respect is a opt-out option. Don't know if this is different in other Bundesländer of germany, but I have gotten a written answer with the above content from the NRW-bureau. ?

Thanks for the info. Plausible is also a nice alternative.

I will send out an expression of interest request nearer the time. I haven't yet decided on a criteria for selection. Current plan is PayPal IPN due to its multi-notifications types. However, I may also do PDT, but not 100% sure at this time. No decisions made yet regarding Stripe's implementation. All frontend implementation is up to the developer. You will have the API at your disposal to do whatever you need to do. In the backend/model, orders can have different status (paid, unpaid, complete, partial, etc). Order line items also have individual status (returned, delayed, refunded, etc). This means you should be able to implement a pre-order feature yourself by, for example, marking an order as unpaid, in progress, etc. Padloper 2 does not render anything in the frontend. It is like ProcessWire. There will be no more in-built Padloper templates. You implement Padloper 2 however you wish using the API. I will, however, as part of the technical documentation, write a tutorial on ajaxifying the frontend. In addition, a separate frontend commercial module (fully functional frontend shop) is in the works. Good question :-). Padloper 2 does not utilise a single ProcessWire field, nor any custom ProcessWire fields, nor any ProcessWire pages (except just the one for the Padloper Process Module). All data is stored in custom Padloper tables. Having said that, it uses ProcessWire selectors just the same way you are used to, offering the same security and ease of use you are used to. You won't have to learn a new syntax. In addition, it is fully multilingual (descriptions, titles, etc). I plan to do a write-up of this when I'm done, a sort of 'the making of Padloper 2', the iterations, decision made, etc. No, you won't be able to do this. Not this way. There are no (ProcessWire) pages in Padloper 2 :-). That said you would still be able to use hooks. You've got some very interesting (albeit very advanced) ideas/thoughts there. Whilst not yet planned, when the dust settles, I'd like to further discuss/explore some of these with you. I cannot make any promises as to the outcome. Yes. There are four types of products (housed under Shipment Type). Physical Products that require shipping. Physical Products that do not require shipping (POS, etc). Digital Products. Products that are Events or Services (e.g., booking system). ---------------------- I hope I have managed to answer all your queries. I decided to just do it inline. I might reference some of the responses in the first post if I need to. Thanks.

Yes, I don't use the wiki but do not be afraid by those old dated thread - check- they will mostly work, I mean, I installed yesterday a module made in 2013 still working without any modifications on the last dev version. Isn't crazy ? ? - https://www.pwtuts.com/ - https://processwire.dev/ - https://cse.google.com/cse?cx=014789015761400632609:fxrf0rj4wr4 and as always, linking this old thread with old videos which still work with the latest processwire version :

Hi everyone, I have released a few PHP 8 fixes over the last week or so, but today's was the biggest with an update to the Adminer core. Unfortunately the automatic login feature of Adminer seems to have been broken for quite some time now, which is why I haven't upgraded it in a while, but now with the need to support PHP 8, I didn't really have much choice. I have managed to implement a hacky way to make the automatic login still work but I'd appreciate feedback on whether you are having any problems with this please. I have of course contacted the Adminer developer about the issue (via the forum because there is no Github issues option ? ) but it's been mentioned by others as well, so not sure what's going on. Anyway, hopefully my hacky way will be seamless enough. PS - not sure what others think, but the context aware Adminer panel is one of the features I use most in Tracy.

2 new methods for Schema.org markup added: print_r($page->fieldname->getjsonLDTimes()); returns an array like this: Array ( [0] => Mo,Tu,We 08:00-12:00 [1] => Mo,Th 13:00-18:00 [2] => Th 08:00-11:00 ) Can be used to create the markup by yourself or echo $page->fieldname->renderjsonLDTimes(); returns a string like this: "Mo,Tu,We 08:00-12:00", "Mo,Th 13:00-18:00", "Th 08:00-11:00" You can use the second method in schema.org Local Business opening hours as followed: ..... "openingHours": [ "Mo,Th,Sa 11:00-14:30", "Mo,Th 17:00-21:30", "Fr,Sa 17:00-22:00" ], ..... Best regards

New feature added: I have updated the inputfield to support multilanguage timeformats on the frontend. You can set the timeformat of each language in the configuration of the inputfield in the backend (see screencast below). Supports strftime() and date() formats. Languageformat.mp4 Version was bumped from 1.0 to 1.1 on Github. Best regards Jürgen

Use a prependTemplate file, where you check for the language and if it's the "not public" one just throw an 404 or redirect. Can even be adapted so translators can visit the site.