Hurme

I'm trying to save new values in some existing user fields. I've tried to google this and found lots of information, but unfortunately it seems I'm still going at it wrong. Here's what I've got so far: Fields are inside a user $dude = $users->get('dude'); Notes is just a textarea field $notes = $dude->notes; This produces a fatal error, why? $notes->set('He's a dude'); But this works $notes = 'He's a dude'; Fatal error again, but maybe I should save the user instead $notes->save(); No error, but nothing gets saved $dude->save(); I also tried adding in the ->of(false) and ->of(true) before and after saving, but that didn't affect anything. So in short, how to change user->field values through api and save the results?

@dragan Hi, I've left the office and wont be back until next week, but I'll see if deleting the cache has any effect. There were no errors in the log files, just your usual "Saved module X". Of course deleting the module itself resolves the crashing issue, but then you can't really use the module.

Hello, I have a clean blank install of latest dev version of Processwire. When I install your module, the backend stops working.

Hi, Field tags, the ones used for grouping up fields in the backend, used to have this feature where you add a "-" in front of one of them and it collapses the group. Now after updating PW the new tag editor is nice, but it's impossible to delete the old -tags. How does one clean those up? Renaming one doesn't do anything. Neither does removing the fields inside one. It seems the "-" in front of the name is preventing PW from changing them. Do I need to delete them manually from the database? And if so where from? EDIT: Figured it out myself. You have to go through each individual field and remove or change the tag name from there, instead of using the tag interface.

And I just noticed what was wrong. My .js file was missing couple of ' around the classes. Typical. ?

Hi @gmclelland, my customstyles.js is shown below. The backend field is set to point: customstyles:/site/modules/InputfieldCKEditor/customstyles.js When I open source code while editing a page there's a line like this: "stylesSet": "customstyles:/(some project folders here)/site/modules/InputfieldCKEditor/customstyles.js?nc=1556022816", So it seems to find its way there, but the styles menu remains empty. I've also tried refreshing the modules like you suggested. CKEDITOR.stylesSet.add( 'customstyles', [ { name: 'Left Aligned Photo', element: 'img', attributes: { 'class': 'align_left' } }, { name: 'Right Aligned Photo', element: 'img', attributes: { 'class': 'align_right' } }, { name: 'Centered Photo', element: 'img', attributes: { 'class': 'align_center' } }, { name: 'Lead', element: 'p', attributes: { 'class: uk-text-lead' } }, { name: 'Large', element: 'p', attributes: { 'class: uk-text-large'} }, { name: 'Small', element: 'p', attributes: { 'class: uk-text-small'} } ]); I also tried with your file (including changing file name to custom-styles.js), but this didn't have any effect either.

@Robin S It works fine now, thanks for your help. Ryan basically gave the same advice in another thread so it should be doubly fixed now. ? @MateThemes It works just fine. You'll want to write it like this: $pages->find("matrix_field.repeater_field.regular_field%=$searchquery, matrix_field.repeater_field.count>0"); Note that you'll want to leave out matrix type. The count part at the end is to make sure it only returns pages that actually have content in them (seems to be a bug and I haven't checked if it's been fixed yet or not).

Thank you very much for taking the time to explain it. This does makes things much more clear to me. I'll report back once I've had the time to test this.

Cheers @Robin S, this makes sense to me. I did read about the named groups while trying to solve this, but the explanation felt a little short for me. What does naming the groups actually achieve?

@Robin S What happens if you have multiple pages, where some of the pages have the matrix and some don't? Does it still work for you?

Unfortunately that doesn't work. "Multidot" selectors can't be used with the | symbol.

I'm going to jump on this train as well. I've got a matrix with repeater inside and then a body field, just like MateThemes example above. This works title|headline|lead|body%=$q Also this works matrix.repeater_field.body%=$q But if I combine both like so, it wont return anything $selector .= ", title|headline|lead|body%=$q"; $selector .= ", matrix.repeater_field.body%=$q; If I try to enclose each line in parenthesis it returns every single page on the website, even if the search word is something that doesn't exist on the site $selector .= ", (title|headline|lead|body%=$q)"; $selector .= ", (matrix.repeaters.body%=$q)"; So I'm kinda almost there, but not quite.

@gmclelland Your explanation was among the threads I read when I was trying to make it work. Here are some things I've tried: 1) Editing site\modules\InputfieldCKEditor/mystyles.js directly. 2) Renaming site\modules\InputfieldCKEditor/mystyles.js to customstyles.js (also changing the CKEDITOR.stylesSet.add( 'mystyles',... to 'customstyles'. Then adding proper path in the textarea fields Custom Editor JS Style Set to 'customstyles:/site/modules/InputfieldCKEditor/customstyles.js'. Basically doing it by your instructions. 3) Trying above but with the customstyles.js in my 'site/templates/js' folder instead. None of these has any effect what so ever. The third option simply wipes the styles pulldown empty altogether.

I've gone through several threads here, but I cannot get this to work at all. Whether I try to edit the mystyles.js in site/modules or create a new .js file in templates/js it's always the same, either it gives the default options or the styles menu is empty without anything. Has there in been any progress on this? Anything new I should take into consideration?

@jens.martsch I tried your "Test for setlocales" code, but it returned nothing on all of the langues (include Finnish which I added). I'll have to try it again once the site is actually deployed on the real server. My current installation is nagging about the set locales on every login, but I'm not very optimistic about finding out what's causing all this.

Cheers @jens.martsch, I'll take a look at your script when I have the time. @wbmnfktr Currently I'm not entirely sure, as I didn't set up the local dev myself. But it is Apache based. Something run by the QNAS we have here. These kinds of things pop up every now and then, even though mostly things work as they're supposed to. I should try to keep more organised notes on when it happens, PW versions, PHP settings and so on. @gmclelland That is what I am doing. It's also set per language in the PW translations. This problem seems to happen every few installations, but not all the time by any means. Which makes it all the stranger.

I tried logging out multiple times during the process, but no go. In the end I wiped the installation and started from scratch, and this time it worked properly. I'm not sure what went wrong on the first time. Don't get me wrong though, PW is hands down my favorite CMS. After 10+ years of suffering with Joomla and occasional WP and Drupal installations, it's very welcome change indeed. @wbmnfktr Setlocale is a big mystery for me. When you read the forums, you find a lot of different information. "Set it in config, no you must set it in _init, no this third place is the one that worked for me". Even after setting it per language in the backend, Processwire will often relentlessly keep popping up the notification that you must set setlocale correctly. I've finished now perhaps 10'ish PW sites, and sometimes it works and sometimes it doesn't. @horst Cheers, I'll keep this in mind.

Hello, I'm unable to return Processwire back to english. Here are the steps I took: 1) I added Finnish language pack on the default language, as the site will be in Finnish 2) I then added a second language and left it empty, in hopes I could use it with my own profile to keep the backend in English. This does not work! Some of the menu items do return to English, but all of the module names and descriptions as an example are still in Finnish. This is a huge pain in the ass as it makes finding modules and reading the descriptions very difficult and confusing when I'm used to using PW in English. 3) I deleted all the Finnish translation files from default, and put them into the newly create language instead. This does not work either. The backend remains a mismatch of English/Finnish when language is set to English. If I set it to Finnish then everything works (e.g. everything is in Finnish). So what gives? Although I love Processwire, I'm also extremely frustrated with how the language is being handled. Half the time it just doesn't work, and don't get me started about setlocale which after dozens of hours of reading through the forums remains a mystery and will not work no matter where I set it and what values I try to use. Compared to other CMS's I've used, PW's language handling extremely difficult and obscure.

I went through quite a few of the collations but none of them had any effect. Just to confirm, you guys think this is still a database problem? If so I'll try to find a solution and post it here if I manage to stumble onto something.

Hello Sergio, I'm not so sure this has anything to do with the collation, but I will try few more. How ever I've never run into this problem before with different content management systems, nor with Processwire when using different forms.

Hi, It was utf8_general_ci before. I changed it to swedish but this did not have any effect and the problem continues. Thanks for trying though. ?

I'm using Ryans default site profile search as a starting point. Only thing I've modified is what fields the search looks into. The site is in finnish and I've run into problems with Scandinavian letters like ä and ö. 1) The search "öö" will find results "oo" which it obviously shouldn't 2) The search seems to add quotation marks " around those letters. Which causes problems in multiple ways. 2.1) I've set the search query to fail if it isn't at least 3 letters long. With quotation marks öö becomes "öö" and so it passes this test, which is not good. 2.2) If the search result doesn't find anything it returns "Your search "query here" didn't find anything." With Scandinavian letters It becomes: "Your search ""öö"" didn't find anything. Which is also not good. Although I can get around this by removing the quotation marks before it prints them it's only a bandaid to something that shouldn't be happening in the first place. Setlocale has been set to fi_FI.UTF8 in config.php, but I'm not honestly sure how to test this, and I don't know if it connected to this issue. I've tried to look into this for a while now, but with little results. Anyone got any good ideas?

Hey, I just wanted to say that this kind of functionality is super important for many websites. I just spend three hours looking for a solution until I stumbled on this. Seriously consider adding it to the documentation. Now I can easily show only news item that actually has content in the relevant language.

I see, so in a way you have to go about it in reverse. I moved the whole hidden problem inside a foreach loop that spits out the search results, but it's good to know this is solvable by the selector alone. Thanks!

Hi kongondo, That was one of the first things I tried, but I couldn't get it to work. Any chance of writing down a simple example? $selector = $pages->find=("(template=x|y|z), (template=a, include=hidden), (title|body~=$searchquery), (bunch|of|other|fields~=$searchquery), (even|more|fields~=$searchquery)") The above obviously doesn't work, and I'm having problems following the logic.