LostKobrakai

The concat fieldtype is not the thing your looking for, but rather the cache fieldtype. It's generating a json representation of all selected fields which you can then search over in one go.

I just want to remind you all, that "users will often only see pages" is an assumption from your experience, but may not be the case for all setups. I'm using lots of custom modules for myself and I've also seen other forum members heavily using custom listers or other custom modules, which all reside in the navigation. @adrian I think your problem with switching between page list and page edit is mostly down to the fact that the page tree is being reset in state all the time and that the page does fully reload. If it would act more like a single page app, which would hold/just update the state of the page tree and maybe even load the page edit interface via ajax this would already feel much more smoothly without trying to cram both interface parts into a single page. In the end a user is most of the time either updating a page or browsing the page tree. Also the gained speed improvements would make switching between both interfaces much more frictionless.

The sanitizer is not meant to sanitize groups of values, but only single ones. It's job is to mask out characters like the pipe just because it does have a special meaning in an selector string. Suppose I'd search for "My | Friend". You most likely wouldn't want this pipe to end up in your selector. In your case you'd want to implode the parts after sanitizing each part.

I just want to add that the access forbidden response is the correct one to return, because the file/folder in the path is certainly not "not found". At least if you want to adhere to the http specification.

@tpr Apigen is a ready made dokumentation generator. The markup/classes are probably not very customizable, so using a framework wouldn't solve much. It's more about finding/creating a color scheme.

Thanks for setting this up. This might actually replace my regular jumps to as it's still a bit faster to get to things by class compared to searching for the file. I've already added it to my browser startpage:

If you're only talking about the navigation then just edit Admin > Pages and unhide the page.

I'm not talking about a phpmyadmin plugin. MariaDB is using plugins as well. To check for the issue I was talking about open the "mysql" database and look into the "user" table. There should be a column at the end about plugins used by the mysql users.

Off Topic: Most users insist on their browser because of saved passwords (and maybe other setup) in only this browser.

Page::deletable has to be hookable because PagePermissions::init does exactly that to implement the default permission setup.

But this will only work if you don't deny robots access to those pages, otherwise they'll index just by links from other pages. At least that's what google says about it.

if($page->isHidden()){ echo '<meta name="robots" content="noindex">'; }

See here: https://processwire.com/talk/topic/12033-get-overriden-field-label/

For my mariadb installation the auth_socket (hope I have the name correct) plugin was the culpit. Disabling it for the user fixed the issue.

It's also been improved on pw 3.0 https://processwire.com/blog/posts/merry-christmas-heres-processwire-3.0.3-and-2.7.3-and-some-more/

Inputfield dependencies work by looking at the input values in the html. If a field is not editable there's no inputfield rendered and therefore no value to be found.

It's matching a lot of stuff, WireArray::getItemThatMatches does need a lot of time and Wire::__get is called damn often, but these are all things to be expected. Also not every page is using all things which potentially could be slow.

One thing I'd like to add is considering to not use pages to store clicks (depending on the scale of the number of users). It's nice to get it up and running quickly, but in the long run a custom mysql table and raw mysql queries for the counting might be more performant.

Came here to ask about a short explanation on what exactly has been done for the "subselector speedup" and now I'm even more curious.

I can confirm this. I've set up a new dev box over the last few days and included blackfire from the beginning and it just works so nicely. I've yet to figure out if the "debugging features" do also allow for steping through the code, but even the performance analysis is so much worth.

It could at least be configurable.

If someone does need feature x of y he can nowadays just pull in the composer package y-x anyways, at least most of the time.

Some nit-picking: There not 100% identical. /** * @return bool Last output formatting value */ $of = $page->of(false); $page->field = "value"; $page->save(); $page->of($of); // Reset output formatting /** * @return obj Returns the page object for chaining */ $page->setOutputFormatting(false)->set("field", "value")->save();

The autocomplete field is a bit of a beast on it's own because it's internally using processwire's search (imho. in a lack of other ajax api endpoints) I'm not sure how well this thing can be configured. But it should certainly not reveal hidden pages (to unauthorized users), which I would consider a bug.