Robin S

Thanks, should be fixed in v0.1.4.

@adrian, thanks for the report - should be fixed in v0.1.3.

Yes, it seems we have sadly lost the ability to manipulate the search results like that. I've used that approach a few times myself. Maybe you could make a GitHub request that Ryan make ProcessPageSearchLive::find() hookable? It looks like manipulating the $items array that the method returns could be a good solution. And maybe add some thumbs-up support to this existing request too: https://github.com/processwire/processwire-requests/issues/214 ?

I haven't found the icons ambiguous so far, but the colour scheme you're suggesting sounds like it would be a good enhancement.

I also see this on the FAQ page: So that is a pretty big chunk of money you could avoid missing out on by simply having a Stripe or PayPal button alone. And think about how much money 10% of all donations adds up to. I'm skeptical of these outfits that sound like they're all about altruism but really they are making stacks of money in the process. Here in NZ a lot of charities raise money via the Givealittle service that is run by one of the big telcos. When it launched all of the money donated was retained by the charities ("we're good corporate citizens"), so naturally it became very popular. Then in 2016 they stealthily started taking a 5% cut. They say that donations are at 22 million per year, so 5% of that is a big fat 1.1 million that goes into their pockets.

You have to enable those fields in the settings of the ProcessProfile module: FYI, you can't use FieldsetTab in edit profile: https://github.com/processwire/processwire-issues/issues/552

Maybe I'm missing something, but in terms of raising money isn't Open Collective basically just a fancy donate button? The only money raised for a project is the money that users donate to that project, right? The transparency features are cool, but is it a lack of transparency that's actually holding back users from donating money to the PW project or PW modules? If people aren't donating currently then it's hard to know for sure why that is, but some possible reasons: 1. It isn't possible to donate (i.e. no donate button exists - presumably because the leader of that project doesn't want to have a donate button). That is the case for PW itself, and I have never heard Ryan express any interest in seeking donations from users. I think he prefers to raise money via his Pro modules. And if users aren't taking that opportunity to support PW via the Pro modules then I think they're unlikely to donate via Open Collective either. With regard to Tracy there have already been several requests for a donate button. 2. 3. 4... Users can't afford to donate, or they never think about offering financial support, or they have thought about it but they're just not motivated to pay money to support the software they use. Or maybe they prefer to support the PW project in other ways - e.g. spreading the word, helping out in the forums or at GitHub, developing free modules for the community, etc. In any of these cases I'm not sure why an option to donate via Open Collective would change their mind. But I'm all in favour of people starring the modules that they use.

I get different results. Using the Sanitizer::translate constant in the second argument means the sanitizer will use the character replacements defined in the InputfieldPageName module settings. So if you only need to account for the German language you can edit the replacements for ü, etc, to achieve a result like that shown above.

Check out the blog post about user-admin-[role] permissions: https://processwire.com/blog/posts/new-user-admin-permissions-automatic-version-change-detection-and-more-2.6.10/#new-user-admin-permissions

https://github.com/processwire/processwire-requests/issues/168

Good idea, thanks. Would have to check with my bank about the options because I already have a prepaid Visa that is my main card, and by default my bank will let the card go into overdraft so would have to set up something special. I gave Leaflet a try seeing as there is already a nice PW module for that. Early impressions are good. Of the tile providers shown here it seems that the only hi-res aerial imagery tiles (which are a must-have for my use cases) are Esri.WorldImagery and HERE.hybridDay. Both of those are fine - does anyone know of any gotchas to watch out for when choosing tile providers? E.g. low usage limits? And I guess it's pretty easy to implement a tiles switcher so you can select between a street map and aerial?

I'm wondering how people here are responding to the new pricing for Google Maps: https://cloud.google.com/maps-platform/pricing/sheet/ For existing projects that stay within the $200 free monthly credit you can get away with not entering credit card details, but as I discovered today all new projects require you to enter credit card details. This is pretty infuriating IMO if you don't want to use the platform beyond the free credit. I'd be willing to have my API access cut off if I exceed the free credit, but forcing you to enter credit card details seems like it is designed to catch people out. I know you can add request caps but those are only for per user per second and per day whereas your credit is per month. It's hard not to be cynical about this and see it as a deliberate attempt to profit from accidental oversights of users. So how are you responding to this? Do you... Require clients to create their own developer accounts? Can't see that being workable. Require clients to supply credit card details that you enter into your own developer account? That would be a problem for me, because most of my clients are NGOs that are run by volunteer administrators, and I think most of them won't have a credit card for the organisation. Plus people can be nervous about sharing their card details with others. Enter your own credit card details? In which case what safeguards are you putting in place to protect yourself from excess usage? Switch to a different mapping platform? Any suggestions for a (free) substitute for Google Maps with similar features and a well-documented API?

@PCuser, I can reproduce it - very weird. My results were slightly different to yours. I've opened a GitHub issue for this: https://github.com/processwire/processwire-issues/issues/666

A couple of things Ryan has said: https://processwire.com/talk/topic/26-what-is-the-autojoin-feature-in-the-fields-editor-and-how-do-i-use-it/ https://processwire.com/talk/topic/613-underlying-workings-of-autojoin/?do=findComment&comment=4948

Oh, right. To work around that limitation you can most likely rewrite your multi-dot selectors as sub-selectors: https://processwire.com/api/selectors/#sub-selectors https://processwire.com/blog/posts/processwire-3.0.6-brings-pages-upgrades-and-link-abstraction/#improvements-to-sub-selectors Although I'm not certain they can be used with OR pipes either. Maybe you'll need OR groups. Let us know how you get on.

No I didn't - thanks for the link!

Ooh, this is a great topic idea! Some of my favourites follow - probably several are already known to folks but I think some will be new to many. A number of these were cancelled well before their time but don't let that put you off watching them. Shows by Jed Mercurio - this guy's work is really original. Sadly often cancelled prematurely, I guess just too far outside of mainstream tastes. Bodies: dark and disturbing medical drama. This was the first Mercurio show I saw. So good. Critical: another medical drama, with extensive surgical scenes. Apparently a lot of work was put into making the language and procedures medically accurate. Requires a strong stomach - at first I thought I wasn't going to be able to take it but it's surprising how quickly you acclimatise, probably just like surgeons do at medical school. The special effects models in this are incredible - I have never seen gore effects this realistic before. Line of Duty: police procedural, a bit more conventional which probably explains why it's still being made. Lots of twists and turns and a cut above others in this genre. Judd Apatow's TV work: Freaks and Geeks is essential viewing, and Undeclared while not quite as good is definitely worth seeing. Both cancelled - what were they thinking? Deadwood: one of the best ever HBO shows, and that's a high bar. If only more people had watched it. Everyone knows that The Wire is a candidate for the greatest TV show ever made (IMO it gets that prize), but check out some of David Simon's other work too. Generation Kill is a first-rate miniseries about soldiers in Iraq, and lately I have been loving The Deuce. Can't wait for the next season. If you're in the mood for some very smart and unconventional stand-up then check out Stewart Lee's Comedy Vehicle. For more dark British comedy see Brass Eye - everything made by Chris Morris is gold. I could go on and on, but one last favourite: Everybody Loves Raymond. This is simply the best multi-camera sitcom ever made. It has many of the same qualities I love about Apatow's work - laugh-out-loud funny while maintaining a human heart and tackling some issues that are actually quite serious. It was obviously an influence on him because of all the ELR references in Apatow films. My all-time favourite episodes: S02E11 - The Letter S04E09 - No Thanks S04E18 - Debra Makes Something Good S05E19 - The Canister S06E17 - The Skit S09E07 - Debra's Parents S09E09 - A Date for Peter

https://modules.processwire.com/modules/limit-repeater/

Don't know about the selector arrays version but here is a selector string version: $selector = "template=facility"; foreach($arr_words as $str_word) { $selector .= ", title|facility_jobs.facility_job_title|facility_jobs.facility_job.job_title%=$str_word"; } BTW, when I have a load of fields I need to search across I often find it preferable to use a Pages::saveReady hook to populate a hidden "index" textarea field with the merged text of the other fields in that template and then just search that index field.

What is $view? The PW core does not have the concept of a view that variables are passed to - there are just template files where the API variables are available. I think this is not a core issue but perhaps you are using some third-party templating module in which case you should raise this in the module's support thread.

Try GitLab Snippets - you can make these private. https://docs.gitlab.com/ee/user/snippets.html

Although if you knew that you had a lot of fields to load for a particular page, or were rendering a lot of fields from other pages, then you could use the load options for $pages->getById() - which can be passed also via $pages->find(), $pages->get(), etc - to autojoin the fields you know you will be accessing. That will cut down the DB queries a lot.

Just the things that Ryan says in the blog post mentioned above: But I don't think it's anything to worry about for most websites. Besides this topic I haven't heard of anyone having any problems with large numbers of fields.

That does sound like a lot of fields. Why is it that the fields can't be reused? You do realise that you can set things like label and description (and loads more since this update) in template context? So you can have a field "text_1" and label it "First name" in one template and "City" in another template, etc.

I was just thinking the same thing and giving them names does fix it. But up until now it hasn't been a requirement for button inputfields to have name attributes.