Leaderboard

--- Please use RockFinder3 ---

Right! Multiple Key support is now included. you can put about 19 in before you run out of space (20480 characters, each key uses about 1040) if someone has 19 keys I will be very surprised. I have bumped the version to 1.0.1 as a result. I ain't a big versioning guy but this is a minor change from the users perspective. you can just click the add button more than once now. Just be sure to only click the save button once you have added all yours keys. I have tried it with the 3x keys I have and it works fine. More than 3? not sure cant test that yet. if you click save before you add all your keys then you will only get the ones you added and have to disable/re-enable Tfa to add them all again. This is a limitation of the Tfa class sadly.

I am back again with another crazy module that might help someone. This time I am using the native Tfa class to add FIDO/U2F support. this includes Yubikeys ? Sadly I cant seem to find a way to do multiple keys at once. and it seems you can only have one Tfa method at a time so not ideal but it was a fun challenge to code and maybe someone will a use for it Github: https://github.com/adamxp12/Processwire-TfaU2F ProcessWire Modules: https://modules.processwire.com/modules/tfa-u2-f/ The code is not the neatest and has limited comments but if you understand the Tfa class it should be quite easy to break apart. And here is a demo of signing in using the Yubikey as the 2nd factor

@netcarver Edited my last reply. I figured it out. Was me being played by the strange design of forms on ProcessWire. It was being converted into a text field for the POST section and the default maxlength for a text field is 2048. doh Now working on multiple key support. fingers crossed with this

Yes! And there's this Tailwind CSS IntelliSense VS Code extension that's excellent: https://github.com/bradlc/vscode-tailwindcss

That should not be too hard ? Actually code completion is also a benefit compared to plain css.

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 ?

Would using a single json-fieldtype for packing config values for multiple keys help? There are a couple I know of, but bitpoet's is probably the most up-to-date.

That is not what I intended. Will fix that ASAP. it should be installable via the ProcessWire admin area just with the class name (once approved) @netcarverthe is a Zip file under the releases tab on GitHub that includes the dependencies that was not included due to my noobness with git (did not know much about submodules to be honest, they just appeared like it as I git cloned the dependencies)

I couldn't say it better than @LostKobrakai did. Thank you! I can only suggest that anyone interested should try Tailwind on a small project to see how it's for real, it's difficult to see its benefits without trying. After you memorize the classes your speed creating layouts will increase a lot.

I've been diving into the core of PW trying to understand performance problems when there are lots of pages, especially ones with repeater fields in their templates. The problem is that creating a page takes seconds (rather than milliseconds) when certain conditions are met. Setup #1 one container page, say /countries/ hundreds of subpages with children, /countries/<country>[/<state>]/<city>/<data> for example create a new page, parent being /countries/ Setup #2 a large page hierarchy with not that many pages directly under one parent, but hundreds of pages with template(s) that each have the same repeater field structure becomes flat again as repeaters use internally page hierarchy of this kind: /processwire/repeaters/for-field-123/for-page-456/1234567890-1234-1 (--> .../for-page-nnn/... are all siblings even when the actual pages are not) create a page with a repeater field used all over the site, parent is irrelevant And of course I've got both of these on one site . Now, what I don't quite understand is what the Pages class method ___save() does just before calling some hooks in the end (from: wire/core/Pages.php): if(($isNew && $page->parent->id) || ($page->parentPrevious && !$page->parent->numChildren)) { $page = $page->parent; // new page or one that's moved, lets focus on it's parent $isNew = true; // use isNew even if page was moved, because it's the first page in it's new parent } if($page->numChildren || $isNew) { // check if entries aren't already present perhaps due to outside manipulation or an older version $n = 0; if(!$isNew) { $result = $this->db->query("SELECT COUNT(*) FROM pages_parents WHERE parents_id={$page->id}"); list($n) = $result->fetch_array(); $result->free(); } // if entries aren't present, if the parent has changed, or if it's been forced in the API, proceed if($n == 0 || $page->parentPrevious || $page->forceSaveParents === true) { $this->saveParents($page->id, $page->numChildren + ($isNew ? 1 : 0)); } } So, for new (and moved) pages it always ends up calling saveParents() for the parent page of the page being saved. saveParents() then works recursively deeper into the tree calling itself for every child page with children of its own. Given the setup #1 this means going through every .../<country>/ and .../<state> and .../<city> page there is. On the other hand, with setup #2 every single repeater instance (.../<for-page-nnn>/) with data inside will be handled. It doesn't really surprise me anymore this takes a while: saveParents() is deleting rows and inserting new ones into pages_parents for thousands of pages, unnecessarily if I'm right. It does seem necessary to call saveParents() for the parent page if the page being saved is its first child (pages_parents has a row for each ancestor of the parent page, but not for the page or parent page itself), but the recursion goes all over the place. I think it should be somehow restricted to the new/moved page and its children (and so on) only. Also, the second argument to saveParents() gets a wrong value when $page refers to the parent page as numChildren has already been incremented for the parent page (though this doesn't actually break anything). As long as new pages can't have children when they're saved for the first time, saveParents() shouldn't be called at all when saving a new page. If child pages may exist, it isn't of course that straightforward but still the saveParents() recursion should be restricted as stated above. I hope my explanation makes sense to you. It's quite possible there is something laying under the hood that I just can't see now having studied this thing for a while (well, hours). But it sure seems like a bug to me .

@netcarver day 2 of existence actually was just a late night idea I decided to go with. The is actually a message that says it was successful and also counts when you do more than 1 key. but I should make it clearer I will look into that. the managing/naming is not going to be possible though as the settings actually vanish once you save the page. This is just how the Tfa class works as far as I can tell. but maybe I am wrong. the is not much documentation on the Tfa class besides the API and the 2x examples from ryan the buttons got added for the initial tests. the Use button does have a purpose. if for some reason it don't automaticity prompt or you accidentally exit the prompt you can use that button to restart the security key process without logging back in again. the submit button is indeed useless though. Originally it was a click the use button then click the submit button but now the JS behind it is more sophisticated and starts the auth process and submits the form on success so I can remove the submit button. but I think the use button could be handy to keep.

I found the commit where that line was added, and the issue that it was related to: Commit: https://github.com/ryancramerdesign/ProcessWire/commit/8d126246772633be773d72f5262acdf14f4c1e31#diff-bbe4731226c86c286f0e4e95a4756eda Issue: https://github.com/ryancramerdesign/ProcessWire/issues/1942 One question that comes to mind is whether a clone should be considered a "moved" page (have a parentPrevious property set), since the original page still exists. If it were considered new instead of moved, I think the line in question would not apply. It still seems like there is a lot of overhead here for a move operation. But I still need to study the issue report linked above more closely.

That's where a good IDE is a big help. Whenever you rename stuff (files or variables etc.) it cleans up for you and searches for usages everywhere in your project.

I have just pushed a commit that cleans up the code a bit. the registered keys are now saved in one field. Again in theory this can support multiple keys... but the bulk of the code is not there as I failed to find a work around to the 2048 truncation. Each key uses like 1040 characters. I could put each key in its own field but that means I have to reconstruct the array and have more complicated JS instead of just concatenating. I am not a huge Processwire module developer so someone with more experience feel free to chime in. I tried adding ->attr('maxlength', 4096) and ->maxlength(4096) and it does increase the maxlength of the field on the HTML side but the processing side is still truncating to 2048 characters even though I cant see where its doing that. the only field that has a hardcoded 2048 limit is the Text field. both hidden/textarea still truncate though even though I cant find the code anywhere that does this. I think it might be a POST request limit?? but surely that would fire a HTTP error instead of getting truncated I feel dumb XD under getUserSettingsInputFields I have to set the maxlength under the if POST section otherwise it will truncate it there. Such a weird design. tripped me up before. but now I can continue trying to do multiple keys ?

Works, thank you for the quick response yet again! :)

Really like what I‘m reading here. ?❤️

Was curious too. I searched and, yes, it was brought up before. Here. TLDR. As mentioned there, it becomes more important when multiple programmers are (or will be--next guy after you) involved. Also mentioned, was the additional benefit of self-documentation when you follow a naming convention. To answer your question, being all implementors of the PW architecture (and PHP), it probably makes sense for us to be consistent with it. (Compared to other frameworks PW made it easy for us.) Still, I did another round of refactoring recently and felt happier after. None of my direct templates have echos. Reduced them to about 10. Since they mostly describe a type of page (model), it's a 1 word all-lowercase filename. I have a couple of controller classes that I camelCased with an .inc extension so the admin wont see it...and added an underscore so its listed on top. I guess we all have different reasons.

I know this is ancient, but I've also run into a bottleneck at PagesEditor::saveParents() on one of my projects running PW 3.0.123. The scenario is as follows: 1. I am cloning a single page (not recursively) which is in a list with several thousand siblings. 2. I am manually looping through the original page's children and cloning them over as children of the new page. (I am doing this manually because sometimes I don't want to clone some of the children) I've timed this entire process at around 7 seconds for a page with just 2 children. Using the Debug timer, I discovered that the initial page and its first child clone over at just .1s each, but the second child clone (and any subsequent children) each take around 7 seconds to complete! Although I am manually looping through the children and cloning them, using PW's recursive clone seems to encounter the same issue. In fact, my test came in at 8 seconds for the same set of pages. The relevant code begins at line 733 of PagesEditor.php where saveParents() is called and passed the parent’s parent when a page has changed parents and it has more than one sibling. It seems that the code is recursing into all of the parent page's thousands of siblings, perhaps unnecessarily. It looks like this line was added in at some point after the fix ryan provided in this thread.

Yes that would be ideal. I could also just save JSON into a string field to lower the dependencies on other modules. I had not thought about doing this actually Food for thought... I will experiment tomorrow I think. I wanted to get a proof of concept working to start with as I had coded a ton of it then realised the settings get locked out once you enable Tfa and then found out that only the Tfa_code field is sent to the validate function. had to get creative with some session variables to get it working but now it works somewhat I feel like I can improve/expand

Looks like this library is added as a Git submodule. The GitHub zip download won't include submodules, so it's a bit of a nuisance. You'll likely need to add them manually, or do a git clone + git submodule init + git submodule update (or something along those lines). Might make more sense to bundle the code directly into the repository, though that's obviously up to @Adam. Either that, or just include instructions on getting those files via Git – though it's probably worth noting that with the submodule approach the module won't be directly installable via ProcessWire Admin (which may or may not be a problem) ?

This is most likely because the module is still waiting for approval ?

Hey @VeiJari, This should be doable by either hooking into the Renderer::renderResults() method and replacing it with custom method of your own (that doesn't contain the path), or simply by setting the result_path template string to an empty string or null via config options: $config->SearchEngine = [ 'render_args' => [ 'templates' => [ 'result_path' => '', ], ], ]; Let me know if this doesn't work, though ?

Oh yeah excellent ! ? PS: The Github link lead to a 404 page due to a typo in the url.

Inside the forum: https://processwire.com/talk/topic/21003-website-free-template/ https://processwire.com/talk/topic/17425-where-will-i-find-more-themestemplates-for-processwire/ https://processwire.com/talk/topic/17953-free-processwire-template/ https://processwire.com/talk/topic/8097-where-do-i-get-premium-themes-for-processwire/ Outside the forum: http://html5up.net/ http://www.opendesigns.org/website-templates/ https://www.free-css.com/free-css-templates https://templated.co/

$page->template->altFilename; $page->template->filename;

If you update to module version 0.9.0 (latest release), you can ? More details here: https://github.com/teppokoivula/SearchEngine#rebuilding-the-search-index. Note that indexing the pages is also possible via module config screen. There's an option for "Manual indexing", where you can either index all indexable pages, or those matching a specific selector.

This is a very old stemming library now so I expect there are better, but I have been using it in production for about 13 years ? so if you don't find anything better, here it is: https://tartarus.org/martin/PorterStemmer/php.txt

Thanks for reporting this. I'm not quite sure why the Modules Directory won't recognise the module version properly, but I've now updated it manually and so far it seems to stick. The info JSON examples at the API ref show a format that isn't actually supported by ProcessWire itself, so it's a possible that this is a bug in the modules directory parser ?

Are there any plans to officially make this compatible with 3.x? At the moment there's quite a few issues. When editing the field itself, it constantly says error geocoding address. In a page containing the field in the CMS it says the same on save, and it also says "REQUEST DENIED" under the map on load. To actually place a pin requires searching and then focusing off the box, pressing return will save the page but not update the marker.

That's likely not going to be trivial. Adding check_access=0 in a selector to display the link is quite another thing as serving the secure file to a guest user. When you have pageFileSecure enabled, the following happens: PW prefixes the file directory site/assets/files/[PAGEID] with $config->pagefileSecurePathPrefix ("-" by default so it will be site/assets/files/-[PAGEID]) When the browsers tries to show the image (i.e. open the URL /path/to/pw/site/assets/files/1258/image.jpg in a separate request), the file isn't found by .htaccess .htaccess hands off the request to index.php index.php calls PageRender::execute with the request URL PageRender::execute checks if the request is to a file, then checks if the page it belongs to is published and viewable by the current user Since $user->hasPermission('page-view', $page) returns false (the guest user doesn't have view permissions) that fails (otherwise, PW would prefix the path now and output the file) PW outputs the 404 page Since the method where the check is are done is not hookable (and some necessary properties and methods are protected, i.e. not reachable from a hook) you'd probably have to hook before ProcessPageView::execute and duplicate a lot of code from ProcessPageView or hook after User::hasPagePermission and at least duplicate ProcessPageView::checkRequestFile in both cases, match the file URL to $page->image to prevent handing out a access to other file/image fields on the page Another approach (if the images aren't too big and the protected pages aren't too many) would be to include the real image data as data URIs: <?php foreach($protected_pages as $protected_page) { echo $protected_page->title . "<br>"; $fn = $protected_page->image->filename; $imgdata = "data:" . mime_content_type($fn) . ";base64," . base64_encode(file_get_contents($fn)); echo "<img src='$imgdata' alt='{$protected_page->image->description}' />"; } If the images are small enough but you have many pages, using PW's pagination might be an option too.

From the documentation you linked to: https://processwire.com/api/selectors/#sort

Absolutely right. I tend to try for 'self-documenting' code, in other words (exactly as you say), naming things based on meaning. This is for templates, fields and other variables. What I also do is use includes in templates for common page elements (which I am sure everyone does) and name them meaningfully. Also grouping template files by purpose is useful. For example, I'll name my includes inc.head.php, inc.foot.php etc, so they are grouped together in any list or file selector. While I was writing, I see apeisa got in before me! I also try to keep things in English, but even for a native English speaker sometimes you wouldn't think I was!