wet

@pete, I think you might consider pulling this PR for security reasons: https://github.com/Notanotherdotcom/ProcessSwitchUser/pull/1

This issue is no longer present with PW 3.0.25.

This is the call stack up to ProcessWire\SelectableOptionManager::getOptions() : I think it is pretty clear. Let me know if I can be of further help.

Scratch that. It looks like Tracy itself causes these queries.

Experiencing performance issues I tried to dig into possible reasons, and this is what I found: I had added an Options field to a template and checked 'Autojoin' because I wanted to sort by this field. This template is used by several thousand pages in my site. When one single page is rendered to the frontend, one database query for each of these 'sibling' pages is run. I.e. rendering a single page causes thousands of database queries. The queries select the current option value for every sibling page of the current page. This is a snippet from the query log with the queries in question: SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(4) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(2) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(3) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(5) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(5) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(5) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(4) SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(3) ...and thousands more... :fields_id never changes, is the id of the Options field. The queries are issued by ProcessWire\SelectableOptionManager::getOptions() . Steps to reproduce: Start with the stock 'site-default' site profile from the devns branch. 2.x might also work, I haven't tried. Install TracyDebugger. Set $config->debug to true. Add an Options-type field (e.g. Select) with a handful of selectable options to the 'basic-page' template. Create a few new pages using the 'basic-page' template. View one of these pages in the frontend, open Tracey's 'PW Debug mode' panel and expand the 'PDO Queries ($database)' section. Find one query per 'basic-page' page stating something like so: SELECT * FROM fieldtype_options WHERE fields_id=:fields_id AND option_id IN(13) I'd like to gather feedback from experienced developers with deeper understanding of the system: Why does PW need the current option value of every other sibling page to render a single page? Wouldn't it be possible to cache these redundant queries if they are needed in the first place? How does this scale when the site grows? How can I achieve sorting by an options field without causing such excessive query counts? Please advise.

Confirmed and reported.

Thanks, very helpful.

Is there a way to restrict the 'Page' field type to allow only a maximum number of pages and enforce their uniqueness? I am trying to build a 'featured products' slide show for the homepage of the target site. 'Products' are, of course, pages. The slide show is yet another page with a 'Page' field to which users can add 'featured pages' by adding and removing their product pages. It'd be convenient if I could specify additional restrictions: I do not want that a product occurs more than once. The slide show's 'Page' field should only contain unique pages. I do not want the user to add less than 4 or more than 6 pages to the slide show. The 'Page' field should not allow to add more than the maximum count and the template should validate upon save whether a minimum count of related pages has been added. I've tried two input input fields: PageSelectMultiple: Cannot find neither a parameter to enforce uniqueness nor to specify count restrictions. PageAutocomplete: Selected pages are unique though they keep reappearing in the autocomplete suggestions. Cannot specify count restrictions. Is there a core feature I could leverage, or would I have to resort to custom coding?

Alan, I assume that you're talking about these differences: Textile <p>...wherever you’re going...</p> TinyMCE <p>...wherever you're going...</p> This difference does not occur because Textile tries to be smart about numerical entities, but about typographically correct quote characters. Textile automatically converts " and ' characters into curly quotes, which is what you see here. TinyMCE simply uses whatever you type. Remember, Dean Allen once was a book designer by profession - which shows.

Hi. I've filed the bug and proposed a probable fix (https://github.com/n...xtile/issues/47)