Leaderboard

@HerTha Just curious is this code fails? $a_sel = [ ['sort', 'name'], ['limit', $limit_per_section], ['template', 'downfile'], ['title|name|indexer', '%=', $sanitizer->selectorValue($a_terms)] ]; $results = $pages->find($a_sel);

Finally fixed @arjen's issue, culprit was a non-readable file within the pwpc directory which wasn't excluded since I forgot exclusion paths need to be site relative (/site/assets/pwpc/ for all ProCache users).

Due to the tooltip problem, the only safe way to copy anything from the forum is to quote the message and then copy from the message composing area.

Fieldtype Page IDs is a third party Fieldtype that, simply put, stores Page references as integers (Page IDs). This fieldtype was built as a quick and dirty workaround for Page Reference fields' inability handle self-references due to circular reference issues. A project I've been working on for a while now includes a combination of RepeaterMatrix content blocks and tagging/categorization system that would've resulted in a lot of duplicate pages (and plenty of unnecessary manual work for content editors) had I used built-in Page Reference fields, and thus a new Fieldtype felt like the most sensible approach. Fieldtype Page IDs was designed to be loosely compatible with Page References in order to make conversions between the two feasible, but it is quite limited feature wise: largely due to the fact that stored values are actually just integers with no connection to Pages whatsoever some advanced selectors and related features are not supported, and page values can't be directly accessed configuration settings are limited to the bare essentials (selector string and Inputfield class) only a handful of Inputfields (AsmSelect, Checkboxes, Text) are (currently) supported Anyway, in case you need to store Page IDs (and Page IDs only) and are happy with the limitations mentioned above, feel free to give this Fieldtype a try. It has been working fine for me in one particular project, but hasn't been tested that much, so please tread carefully – and let me know if you run into any issues. GitHub repository: https://github.com/teppokoivula/FieldtypePageIDs Modules directory: https://modules.processwire.com/modules/fieldtype-page-ids/

Using %= means your value will be escaped and wrapped in "%$value%". Using that with LIKE in sql means you'll get all results returned for an empty string value. Both – returning an empty or a full resultset – can be valid expected results for a filtering operation so it's best to align with the default sql behavior and not adding special cases, which is at least the less surprising option. If you don't want to allow searches for empty string is ultimately a business decision you have to take care for on your own. If that's a concern I'm wondering if you don't set limit on your query. Limit (and in extension pagination) makes the problem of an empty string not filtering the results a non-issue.

I found some other strange stuff (only tested in Tracy): $q = "*"; $query = $sanitizer->selectorValue($q); $pgs = $pages->find("parent=1041, include=all, vertec|title|name|remarks%=$query"); d($pgs); This returns everything. Every single page inside parent id 1041. ! returns a seemingly random amount of results (74 out of 1061) - completely wrong. ? does the same, but returns 73 instead of 74. So, I guess you'd have to manually sanitize the query yourself: Check if minimum string length is 3. Remove charactes such as ! & *. And of course, make it a habit to narrow results down (according to template, parent, not in trash, etc.). I would expect PW to throw some sort of error if a search string is less than 3 characters. Maybe the results may differ if I actually used it in a template (outside Tracy) and not logged in as superuser, or with debug off. But still, this behavior truly puzzles me.

further investigation - I simplified the code to: $a_sel = [ ['template', 'downfile'], ['title|name|indexer', '%=', $a_terms] ]; $results = $pages->find($a_sel); So, there are 3 fields to search: "title", "name" and "indexer" (a textarea field). Still using $a_sel = "&hallo". It turns out, that the error occurs only if: "name" field is present and at least one more field is present The combination "title" with "indexer" works just fine. I have never filed an issue report, but this one could be worth it. Anyone who can duplicate this error?

that extra sanitizer removes the error, Tracy reports $a_sel to be: So, for this case, the documentation seems to be wrong:

It's just manually enforcing the string is escaped in quotes, but single quotes this time. Since I guess that double quotes are removed somewhere, you may try with this one as well: ['title|name|indexer', '%=', '"'.$a_terms.'"' ] In both cases you really need to ensure the search term does not contain quotes itself, searching for "it's" will fail now. That's normally something $sanitizer->selectorValue() takes care of.

@AutofahrnDanke for your hard work on this. I really appreciate it. I've excluded both pwpc and added the regex to the config. No luck. I then changed the "Absolute path of the directory where packages are saved." to the ../public folder. No luck either. Funny thing is though that the log says it still wants to save in the "default" folder. When I add your code I'm getting a "Parse error: syntax error, unexpected '$res' (T_VARIABLE)". I've double check the syntax, but it seems to be okay. Not sure what is going on there as well. I also removed all filecompiler files and let it recompile again. No luck.

@HerTha I use such code: if (input('get', 'q')) { $query = input('get', 'q', 'text'); input()->whitelist('q', $query); $selector = [ ['template', 'post'], ['title|builder.post_wysiwyg|builder.blockquote_wysiwyg', '%=', $query], ['limit', '10'] ]; } and it also works with '!' without errors. Consider using selectors as arrays as it more clear way and have on a small benefit that you don't have to use $sanitizer->selectorValue()

1. If you put your PHP file in the site root it won't be affected by the htaccess restrictions. You could also put it any other place besides those places with restricted access. 2. See the "Files" tab in the template settings: "Disable automatic prepend of file..." / "Disable automatic append of file..."

Much love to you and your family Ryan, haven't had that experience before, and not looking forward to having it in future - cats make a bigger difference to your life than you'd think! Thanks again for all you do.

News Update - 3 May 2019 - Part One The little speckled fella has been very busy on the trail. Despite being the smallest of its kind, she has lofty dreams. We've been working on the API and the Products GUI. In the next post, I'll tell you more about the API. Products Features and GUI Though there are a few issues still pending (aren't there always? sigh), I am relatively pleased with the results. Of course, during beta testing we'll received and incorporate feedback as best as we can. Only UI-Kit theme will be officially supported. Multilingual fields if site is multilingual Ajax powered inputs for fast and convenient editing Four types of products Physical product requiring shipping Physical product not requiring shipping (for collection) Digital product Service/Event (etc) products - e.g. Swimming lessons, Consultancy services, Hotel booking, etc Product Classification (ajax powered) by: Type: e.g. Belt, trousers, etc Brand: Puma, Sanyo, whatever (editors can type in or import brand names + planning to support logos) Categories (aka Collections): Multiple categories, e.g. Men, Girls, Hospitality Tags: Multiple tags can be entered, e.g. sale, amazing, etc Product Variants (consists of an Option (e.g. Colour) and an Option Value (e.g. Red) Add zero or n variants as you wish Live preview as you build variants Each created product variant can be enabled/disabled. Devs can then decide to either show that variant as unavailable or not show them at all. That's up to you :-). Apart from classifications, shipping class, inventory policy, weight and dimensions units, title and description (and this latter one may change), almost all product properties will vary by variant if variants are used Product properties include: Images Colour (more on this below) Downloads (centralised and reusable) Price and Compare Price (aka former price) Inventory policy (whether to track or not) Charge taxes SKU (stock keeping unit) Inventory (quantity) Allow back orders (aka overselling) - @note: this can be set per variant. This is useful if one variant can be restocked faster than others Weight Length Width Height Weight Unit (mg, g, kg, oz, lb, t) Dimensions Unit (mm, cm, m, in, ft ) Shipping Class - can be used for product-based shipping if needed (e.g. bulky goods, light, fragile, small items, perishable, etc) Images (more on this below) Downloads (more on this below) Images Multiple images can be added to both a product and its variants (in case its has some). Images add to the product itself can be used with all variants Images added to a variant are tracked/tagged as belonging to only that variant In some cases, it may not make much sense to add different images for similar variants. For instance, a small red hat and a large red hat could probably share the same images. Although we do not currently support specifying an already uploaded image as belonging to a group of variants, this may change in the future Colour Similar to images, can be set at both product and its variants level Colour saved in RGBA format Downloads Also similar to images, can be populated for both both product and/or its variants Multiple files can be added to a product A file designated for 'whole' product will be available to download irrespective which variant of the product was purchased Conversely, a file or files saved for a variant will only be available to the buyer if they buy that variant of the product The above is useful if you want buyers to be able to download different files of the same product. For instance, recently someone needed to sell two versions of a font as part of one product. This is a solution for such cases. TODO List Lots! e.g. default settings for some properties, e.g. weight unit, shop currency, etc. For the frontend, we are creating a rich language-aware API that you can use to build your shop however you want. There will be no rendering of markup (but see first post in this thread about a separate fully functional frontend shop). In the next post, we talk a bit about the API. Before that, here are some screenshots and a video demo (if you can spare some 20 minutes away from watching, er..., cat videos? ?) Screenshots Video Demo Thanks ?