Leaderboard

In ProcessWire 3.0.160 we’ve got some major upgrades and additions to our text-matching selectors and operators. This brings a whole new level of power to $pages->find() and similar API calls, especially when it comes to search engine type queries. This blog post also includes a demo search engine that lets you test everything out live— https://processwire.com/blog/posts/pw-3.0.160/

Thanks for the reply teppo! You're right, i definitely should use php 7.3, I also tried that. I just developed the site on php 5.x and wanted to keep the settings as similar as possible. I'm talking to the namecheap support right now, if I can solve the issue with them I will post it here for future reference.

@encho you pointed to something I hadn't thought of before reading your comment. I then tried all the afternoon to work on that - I have to brainstorm more about that, but I think we could have something which works. In this sample, you can see a heading and a paragraph written in a CKEditor field. You can then change the fieldtype to EditorJS and get you saved data. As you can see - and as you stipulated as well in your last comment - the strong tag isn't taken into account. Anyway, I am quite confident to get a parser working here. I still take into account that I am not aware of how/which DOM are inserted on every CKEditor for a given user. I was thinking to alert the user if his content couldn't be parsed entirely, or something like that, and so, a manual intervention will be needed in this case. And this is how look the paragraph with inner DOM elements, should be "easy" to insert them :

Timestamps can a be a tricky source of truth in some cases. What if the editor and the script started at the same time? Speaking of which, which process is your single source of truth? The editor or the script? I mean, when there is a conflict, whose changes do you want to accept? I was thinking of something along the lines of what @horst suggested, i.e. separate fields for the script vs the editors. It's hard to get away from a manual intervention if there are conflicts. Given the situation you've described, I'd be very surprised if you manage to avoid manual oversight in case of conflicts.

You can filter by dates like so: $events = $page->children('limit=50, date<=today, sort=-date'); Also check this thread to see more details: date_start>=today date_start>=1365436783 date_start>=2013-04-08 date_start>=4/8/2013 date_start>=8.4.2013 date_start>="April 8, 2013"

Ok, when you want to hide the merge or collision handling away from the editors, you have to make the auto process aware of opened pages, and maybe the opened one should be excluded or queued for later processing. Or: Is it right that the auto process modifies not the same fields that editors do? If so, maybe it is possible to hook into those page saves and then only save content to fields allowed by user roles? Foreach allowed field setAndSave (Sorry, on mobile)?

In the documentation or somewhere else bound to the User Activity module you can read that the core Notification System already has some bare features available, like detecting multiple users or tabs with the same opened pages. Maybe looking into it can reveal some useful bits. ??

Doesn't that pro dev tool thing have a feature to show user activity. Couldn't that be intercepted to accomplish your goal? I'm just thinkin' out loud.

No worries, I get what you're saying ? The way SearchEngine is built makes it (in my opinion) really simple to use when you basically just want a search feature and are happy with some visual modifications to the form and list of results etc. But once your needs get more complex, there's a bit of a learning curve there. I've tried to keep the complexity to bare minimum, but it can still be a bit overwhelming at the beginning, especially if you're not particularly familiar with the way ProcessWire itself works. You can definitely do the kind of query you mentioned above with SearchEngine. At least for now the index field is just a regular FieldtypeTextarea (or FieldtypeTextareaLanguage for multi-lingual sites), which means that you can perform queries against it just like with your own custom fields. +1 to this right there. Selectors are one of the biggest arguments for ProcessWire: not only do they make complex queries a breeze, but by sticking with them you can easily avoid some of the gotchas you'd have to worry about working with raw SQL (injection attacks, etc.) Behind the scenes almost every field you see in the admin is what one might call a "custom field", and each of those has a database table of its own. ProcessWire makes extensive use of JOIN queries, which do indeed make things more complex if you're trying to write raw SQL, but again: this is something you should almost never do anyway ?

[18-Jun-2020 03:42:32 America/New_York] PHP Fatal error: require(): Failed opening required '/home/niklcicr/public_html/wire/config.php' (include_path='.:/opt/alt/php56/usr/share/pear:/opt/alt/php56/usr/share/php') in /home/niklcicr/public_html/wire/core/ProcessWire.php on line 1199 I don't have an answer to you, sadly, but looking at the post you linked to, this seems like a different issue. In that other case the problem was that the host only had 32MB of memory available, which wasn't enough to actually run (or even install) the system. In this case it seems that PHP is unable to include the config file. I would start by making sure that it actually exists in the path mentioned above. If it does, it could be a permission issue: depending on the setup PHP may be running as some user that doesn't have access to this file. Could also be something entirely different, so what I'd really suggest doing would be contacting support on the host in case they've got an idea what's going on. Note: this is a little off-topic, but your host is running PHP 5.6.40. That's a very old version that hasn't received official security updates since January 2019, so I'd suggest updating to PHP 7, and preferably at least PHP 7.3. And if that's not possible on this host, it might be best to look for a new one... ?

I am aware of the fact that Editor.js can do html, it would be easy that way to just do in-place swapping the text field with the new one. But it would also be nice to move old texts to json. I see it discussed in Editor.js Github so there must be a way. One workaround I can do is to dump my database and then run some custom regex search/replace to remove <p> and other tags and replace with json key/values. Problem is there are so many variants, spans, divs, and stuff pasted from word that it is very difficult to anticipate all the options. Did this in past when I was trying to replace <p><strong>***</strong></p> with <h2> enclosure. Web editors/moderators never learn and this Editor.js approach seems to be closest to neatness perfection and keeping everyone happy along the way.

@Kola - glad you figured it all out ? The key thing here is that it's not really the ASMSelect inputfield, but rather the Page Reference fieldtype that's behind it - because you have that set to store multiple values you need to use the add() method. Same would go for checkboxes etc.

There's no need at all to understand the PW architecture or database structure and relations - or even to think about these things. Stick to using PW selectors (https://processwire.com/docs/selectors/) and all the hard work is done for you. Selectors are one of the really great features of PW! (Note that if you later decide to use RockFinder for the extra speed, it also understands the PW database structure so that you don't have to.)

In the blog post last week we looked at some of the two-factor authentication system upgrades, like the new “remember this computer” feature. This week I finished off the remaining parts, as well as released new versions of both the TfaTotp and TfaEmail modules. Auto-enable TFA support We now have auto-enable support (forced 2FA), which lets you setup two-factor authentication for users, without their input (if they haven’t enabled it already). This is a good way to add a lot of security for very little work. Currently, the module that supports this is the TfaEmail module. That’s because it’s a safe bet to assume the user has access to their email, even if they haven’t specifically setup 2FA. So email is a very good way to nudge people into 2FA, and people are already used to this, as many online services now do it. Considering that the computer can now be remembered, I think it’s unlikely you’ll get any complaints from users. Setting up auto-enable is really simple. Grab the latest version of the TfaEmail module and install it. Then go to your ProcessLogin module settings (Modules > Configure > ProcessLogin) and you’ll see an option there to select Email in the “Force two-factor authentication - Type” field. If you want to limit this to specific roles, then you can also do that here. If you don’t select any roles, then it applies to all roles. Once setup, any user logging into your admin will be asked to enter an authentication code sent to their email, and they’ll need that code to complete the login. Chances are they’ll also click that “remember this computer” checkbox so that they can skip the code on future logins. TfaEmail version 2 The new version of the TfaEmail module also lets you now configure what WireMail module you want it to use for sending authentication emails. If using multiple mail sending services, you’ll want your most reliable and fastest email sending service to handle these kinds of transactional emails. TfaTotp version 4 Once users understand the benefits of 2FA, chances are they’ll want to upgrade to TOTP, where they can use a dedicated authenticator app. The ProcessWire TfaTotp module got several upgrades this week. The biggest was the addition of a locally hosted QR code generator (QRCode for PHP by Kazuhiko Arase). No longer does it have to rely upon an external service to generate QR codes (previous versions used Google Charts for QR code generation). In addition, the TOTP TwoFactorAuth library has been updated to the latest version. Moving those modules to the core Speaking of those two modules (TfaEmail and TfaTotp), thanks for your input last week about their inclusion in the core. It sounds like most think it’s a good idea, so I think we’ll go that route. But I need a little more time to do that, so going to hold that update and the 3.0.160 version bump for next week. Coming next week: Useful new selector operators Next week I’ve also got a couple of special new text-matching operators being added to our selectors system that I think you are going to really like. They are operators that are especially useful to those building text search engines, and ones that I’ve found so useful this week that I wish we’d had them since the beginning. I’m excited to add those into 3.0.160 and tell you more about them next week. By the way, while 3.0.160 isn't officially the version on the dev branch yet, if you download the current dev branch version (3.0.159), all of the TFA updates mentioned above are present and ready to use.

I found the solution. By amending this line in LanguageSupportPageNames module, we can set any template to bypass the language segment of the URL. It would be great if this can be editable in the module setting. Right now, we can just copy the module to /site/ and override the module inside /wire/. Hope this help somebody looking for the same api approach for multilingual sites.

ProcessWire must leave it up to you to handle those 404 errors, as it cannot know when to throw that error. Maybe your result of find() will get pages added at a later stage of the process, which wouldn't get called if pw would throw an 404 error right after the find() call. $list = $pages->find("stuff=selected, limit=10"); // if list is empty and it's not the first page if(!$list->count() && $input->pageNum != 1) throw new Wire404Exception();