bcartier

Thanks Dave!

Hi Dave, I'm having the same problem - trying to set the page name in another language, and setting it to "active". I looked at the page you pointed to in your [Edit], above, but I'm only seeing a way to read those values... Would you mind sharing what worked for you? Thanks!

It struck me today, as I was working on a large site, that it would be really nice if the Setup -> Fields fly-out menu would implement the "Tags" feature to group fields into sub-menus. I use Tags (defined under the 'Advanced' tab when editing a field) to neatly organize fields on the actual Setup->Fields page. It would be great if the menu was also organized the same way. A single fly-out menu of 50+ un-grouped fields isn't so useful... What do you think?

I've been using Digital Ocean along with https://serverpilot.io/ as an easy way to manage the server(s) - it's a great combo!

Good call teppo! It could really simplify the UI to have fewer options in the drop-down and a "Not" option as a checkbox, but the challenge might be in the label, and how that might work in various languages.

Would it be possible to add a Lister filter for text fields: "Does Not Contain"? I'm looking for the opposite of "Contains Text" shown below. We have "Not Equals", but no negative operator for partial string matches. Is this omitted because of performance concerns? Thanks!

Sparrow - I've updated the original post with screen grabs.

This started off as an experiment - tweaking the existing Futura colour scheme using browser dev tools to find the places to edit. I was trying to create a less intimidating admin for my clients. So it's not ideal in that it's not a proper module, and it's not taking advantage of CSS preprocessors etc. But, I thought someone might like to try out this 'subtle' take on the admin theme. Like I said, it's just a hack - so just replace /wire/modules/AdminTheme/AdminThemeDefault/styles/main-futura.css with this version. Then in Modules > Core > AdminTheme choose "Futura". I've only tried it on the dev branch 2.4.13... If there's any interest, I might make a proper theme Module with it... -Brent Edit: added screenshots main-futura.css

I really like where this is heading! I'd like to see it handle all Modules as well... It could really improve our workflow.

Thanks apeisa, That works except that I want to use the resulting pages as part of a $pages->find( ) not just at run time. For example, If I have a Template and set of Pages representing Cities, and another Template and set of Pages representing Laws. I want to have a FieldTypePage in the Laws template that allows Cities as children, and use InputFieldSelector to make it easy to add page references. Then I could use Subfield Selectors to find all Laws for a given city/cities. With just the SelectorFieldType, I could output what Cities apply to a given Law at runtime in a template, but I can't access those values for searching/filtering. Make sense?

On the dev branch 2.4.9, is it possible to use the new InputFieldSelector with the Page Fieldtype? I'm looking to use Selector to provide a better UI for selecting large, complex sets of pages as Page references. Currently, I'm able to set up a Page field using Selector as the InputField, but when saving a page with this field, nothing is being saved to the DB. Not sure if this is planned for 2.5 but I'm trying it a bit too early, or maybe I'm missing a step in the setup... Thanks!

Incredible work guys! I agree with other comments - this is a game changer for ProcessWire. Thank you so much!

Hey Mike, If you're looking for a more engaging way to collect info, I highly recommend TypeForm. Although not a ProcessWire solution, it's really a great service that's easy to embed. Have a look at some of their sample forms - I think you'll be impressed. They also make it easy to view, download and filter the data collected as well. -Brent PS: I don't work for TypeForm - I just really like it ;-)

Hi Ryan, I'm trying to use various operators in Pages Web Service, but some of the operators do not seem to be working. ^= Contains the exact word or phrase at the beginning of the field The key-value pairs using this operator are completely ignored. The [selector] part of the response only includes other key-value pairs. request: ?template=industries&title^=Tire&debug=1 response: [selector] => template=industries, limit=50 ...I tried with '%=' and it works fine: request: ?template=industries&title%=Tire&debug=1 response: [selector] => template=industries, title%=Tire, limit=50 ...also with *= works fine: request: ?template=industries&title*=Tire&debug=1 response: [selector] => template=industries, title*=Tire, limit=50 and, of course '=' works: request: ?template=industries&title=Tire Manufacturing&debug=1 response: [selector] => template=industries, title=Tire Manufacturing, limit=50 $= Contains the exact word or phrase at the end of the field The key-value pairs using this operator are completely ignored. The [selector] part of the response only includes other key-value pairs. (as above) ~= Contains all the words Always throws an error because that field name is not searchable . The ‘~’ symbol is converted to ‘_’, is considered part of the field name and not treated as an operator. request: ?template=industries&title~=Tire&debug=1 response (error): Field 'title_' is not allowed in queries ... I tried disabling the sanitizing of the field name before the error is displayed (line 189), and it then shows the error with the field name being title~ request: ?template=industries&title~=Tire&debug=1 response (error): Field 'title~' is not allowed in queries I tried looking through the module, but I'm not seeing the cause of the problem. Any help would be greatly appreciated! Thanks, -Brent

I think you're looking for Subfield Selectors?

Good point - it's closer to how PW is handling languages that way. I like the idea of a lang=all for my edge case though ;-)

I see what you mean apeisa, but in some cases, you might want to get all the data in a single call, no?

I'm using TextLanguage and TextareaLanguage fieldtypes for a multi-lingual site. When using Pages Web Service, the resulting json data only ever includes the default language value for a multilingual field. I think this is what davydhaeyer was asking about (above)... Would it possible to extend Pages Web Service to support multiple language fields? Ideally I think it should return all languages in the json response. It would also be great to be able to specify a language in the request, which would limit the response to one language – which would flatten/simplify the json response in that case (as it's doing now, but it's only doing it for the default language). -Brent

As a temporary solution, I've had success adding a 'global' folder containing "templates-admin" and "modules". Then I modified index.php (in the root of the ProcessWire install) like so (modified lines marked with a comment): /* * Setup configuration data and default paths/urls * */ $config = new Config(); $config->urls = new Paths($rootURL); $config->urls->wire = "$wireDir/"; $config->urls->site = "$siteDir/"; $config->urls->modules = "$wireDir/modules/"; //EDITED HERE $config->urls->siteModules = "global/modules/"; $config->urls->core = "$coreDir/"; $config->urls->assets = "$assetsDir/"; $config->urls->cache = "$assetsDir/cache/"; $config->urls->logs = "$assetsDir/logs/"; $config->urls->files = "$assetsDir/files/"; $config->urls->tmp = "$assetsDir/tmp/"; $config->urls->templates = "$siteDir/templates/"; //EDITED HERE $config->urls->adminTemplates = is_dir("global/$adminTplDir") ? "global/$adminTplDir/" : "$wireDir/$adminTplDir/"; $config->paths = clone $config->urls; $config->paths->root = $rootPath . '/'; $config->paths->sessions = $config->paths->assets . "sessions/"; It would be great if the file used for routing (index.config.php) could handle this kind of override, so that we don't have to worry about replacing index.php during upgrades... Hope that helps someone!

Thanks for your thoughts Ryan! My specific use case is selecting from a large but mostly static set of pages. One example is selecting from a set of municipalities. The page tree structure is Country > Province > Region > City. What makes a selector work so well in these cases is that this hierarchy has an existing code system that represents the hierarchy. A province might have a geographical code of 35, then a region might be 3506 then a city would be 3506008. This makes using a selector easy, because the content editors know the geographical codes well (and there are lots of external references they could use. In this case I do need to store both the selector and also store page references. I want to be able to find pages that have a specific geographical code as a page reference. I think the module adrian mentioned already does a good job of storing the selector and creating the page array at run time, but the main use for my case is to be able to query the page references like pages->find('template=program,code*=35') to find programs that apply to the province and all it's municipalities. Should I continue looking into extending FieldtypePage? I assume would have to add another table? It would store page_id and the selector, as opposed to the default for page references, which is page_id of the parent and page_id of the referenced page (one row per reference)... right? ^ EDIT: Actually, if working with the DB is feasible in an InputField, it would make more sense to create the "selector" storage table as part of the Inputfield. That way I wouldn't have to extend FieldtypePage at all. Ryan - do you agree that this would be an acceptable case for bending the rule of only using Fieldtypes for DB manipulation? Thanks again for your help, -Brent

Thanks adrian, Looks like a new FieldType that extends the core Page fieldtype might be the right way to go. It's turning out to be a bit more complex than I was hoping - expecially for a first module ;-) -Brent

Thanks adrian So far the addon is only an InputField. Is there a way I can leverage the DatabaseSchema from the InputField, as opposed to a FieldType? Will I need to create a custom fieldtype that extends the Page fieldtype? Really appreciate the help! -Brent

Hi guys, I'm creating a simple InputField for selecting multiple page references. It displays a text field that accepts a PW selector. When you click the "Apply" button you see a count of matching pages. The use case is selecting large numbers of pages from very large page sets very quickly without slowing down the edit page form. I've got the selector query working with the Page Search API (populating a hidden field, just like PageAutocomplete does). Saving the page creates the references. The missing piece is saving the actual selector. The InputField currently extends InputfieldSelectMultiple to be able to save multiple page refs, so I'm not quite sure how to also save the selector the user enters to get those pages. I starting this thing by working from PageAutocomplete, but I wonder if I've painted myself into a corner. I was hoping someone might have some suggestions... Thanks for you help! -Brent

Thanks for the help! You guys are fast

Well, as usual, that was easier than I thought. In case others overlook the same thing, I was able to access those settings with the following: $field = wire('fields')->get($this->name); $template = $field->template_id; $parent = $field->parent_id; $selector = $field->findPagesSelector; $code = $field->findPagesCode;