adrian

Looks like the OR selector you were trying to use is now working in the latest version v20 that Ryan posted in the PF download thread. Note that this is actually "0.2.0" - I have never understood why he is inconsistent with those version numbers like that ? There are also changes to the PW core around this issue, so you should probably update to the very latest dev commit, although I actually found that what you were trying to do worked before I did that update.

@FireWire - just a reminder to remove the bd($content) call in Fluency.module.php Also, just want to agree with @xportde's request for a dedicated permission. I have already changed it locally to add a "fluency" permission. In my use case I actually needed to give the guest user this permission so that I could do translations via a cron called script. Thanks again for your work on this - I am now using it in production.

Yes of course - sorry, my bad. The old system did end up creating a bunch of extra users, often without the module author realizing it. Glad that won't be an issue going forward.

Oh wow, you have been busy ? Definitely weird that you are tagged as the sole author of some modules that aren't yours at all, eg. Admin on Steroids (https://processwire.com/modules/admin-on-steroids/). There is definitely something amiss here @ryan

I wonder if it would be parsed correctly if you replaced those entities in your name with UTF-8 characters?

https://github.com/matjazpotocnik/AutoSmush/blob/3b9028c92bb4b380b542a479fd62a235f583968f/AutoSmush.module#L31

@matjazp - not sure why, but it doesn't seem to be all modules, eg: https://processwire.com/modules/cookie-management-banner/

Hi @VeiJari - are you referring to table subfield labels vs names? Names can already be added to the header row with the poorly-named "Column labels" option. Does this do what you need, or do you want an option for the actual Label instead of the Name?

Hi everyone, I have released a few PHP 8 fixes over the last week or so, but today's was the biggest with an update to the Adminer core. Unfortunately the automatic login feature of Adminer seems to have been broken for quite some time now, which is why I haven't upgraded it in a while, but now with the need to support PHP 8, I didn't really have much choice. I have managed to implement a hacky way to make the automatic login still work but I'd appreciate feedback on whether you are having any problems with this please. I have of course contacted the Adminer developer about the issue (via the forum because there is no Github issues option ? ) but it's been mentioned by others as well, so not sure what's going on. Anyway, hopefully my hacky way will be seamless enough. PS - not sure what others think, but the context aware Adminer panel is one of the features I use most in Tracy.

@ryan - any chance you can take a look at this please - I do think it's pretty important that the "Updated" data is accurate. Thanks!

@kongondo - not sure what happened here. I actually just had to reset my sandbox install (mysql issue when upgrading to PHP 8) and now everything seems to be working fine with the example I posted above. I get the feeling this issue might appear again in certain circumstances but not sure how to reproduce at the moment.

Definitely excited by this - seems like potentially some huge performance gains depending on how you are querying and rendering the field data. Just wondering how far one might take this - I can imagine sometimes using it for all fields on certain templates. There are a few times I have used a Profields Table field but limited it to just one row so that I have a simpler way to query those subfields directly with SQL, especially when I want to summarize numeric data across many pages. Anyway, thank you very much for this!

Hi @VeiJari - this isn't an issue with this module, but rather the selector system for the Table field. You can test that yourself with the Tracy console: d($page->log_usage_table('pr_location=1025|1027')); and you'll see the same problem. So, I think this is a question for Ryan. Here is a discussion about OR selectors in Table (https://processwire.com/talk/topic/24508-what-is-it-with-profields-table-and-or-selectors/), but it's not specific to Page Reference subfields so you'll need to bring that up specifically.

Completely agree - it's a must on every site.

The multiple save issue that you brought up reminds me of the way ProfieldsTable works - you need to save the field settings twice in order for a field order change to stick.

Ok, so here is the reply from DeepL "We experienced a temporary technical problem earlier today. As you noticed, the issue has already been resolved. It is rather seldom that we experience outrages. Should this occur, we strive to resolve the issue as fast as possible, as you have seen it today." Nothing terribly illuminating, but it does suggest that outages are to be expected (as I suppose they are with any service), but I think this means that we do need a friendlier way of catching and handling errors.

FYI - looks like everything is back up again, but I'll still be sure to post here whatever I hear back from DeepL as to what the problem was.

For some reason I can no longer call the API. I am seeing errors like this: "HTTP Code: 0 API Message: No message returned Request Endpoint: /translate Parameters:" On pages that call the API, I am also seeing this: "Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later." I am not sure exactly what is needed yet, but it seems like there might need to be a try/catch or some other approach so that things just don't break. I am also going to contact DeepL and see if there is a known issue at the moment and how often things like are likely to happen, because it could be really messy for my use case using the API directly. I guess for translating fields in the admin it's not such a big deal, although you still want to make sure it's handled properly.

@FireWire - not sure if this is a bug with your module, or the DeepL API, but if I include a two word business name, eg: "Amazon Prime" in the Global non-translated strings, and then I translate a sentence that is like this: Visit Amazon Prime. Next Sentence. then the returned translation looks like this: Visite Amazon PrimePróxima frase. with the period and space removed. Please let me know if you have any problems reproducing. I have discovered that I actually don't need to add it to the non-translated strings because DeepL is smart enough to realize that uppercase in the middle of a sentence shouldn't be translated, but I expect this might be an issue with lower case non-translated strings. Thanks for looking into it.

Jeez, you're a bloody legend ? This feels much nicer! You really went the extra mile with supporting this request - much appreciated. Thanks again.

Thanks Robin - I guess I thought that if you applied the "HannaDropdown" option to the CkEditor settings, that would be indicative enough that you wanted to process that field and widgetise the strings, but I do understand your second point. The hook you provided is a good solution, although now that I have applied the hanna code text formatter, I do need to also use getUnformatted() on the body field when outputting content on the site so that it isn't processed by Hanna. I think it would be nice if PW had a dedicated way to remove a specific textformatter when outputting so that others are still applied - I don't think that is possible though.

@Robin S - sorry, turns out it wasn't a repeater issue, but rather because I didn't have the Hanna Code Text Formatter applied to the textarea field. The thing is that I don't actually want it applied because I handle the replacements myself with my own template code rather than code within the Hanna rule. This doesn't prevent me from applying the text formatter to the field anyway, but what does prevent me from wanting to do that is that I use the text as the label for the repeater item and I want the hanna code to show in that label, eg, I don't want this: but rather this: Do you think you could alter things so that the text formatter doesn't need to be applied to the field?

@Robin S - not sure if this is a new issue (maybe a change to the PW core - I am running latest dev version), but it looks like the dropdown is not showing when the field is in a repeater. I haven't looked at this field in a while, but I am pretty sure it used to work. Let me know if you can't reproduce and I'll look into it more. Thanks.

Yeah, I think so for sure.

New field (created via GUI) without tags: Then apply: $field->useTags = 1; $field->save(); but nothing happens yet. But then reload the field settings page in the admin and now it looks correct: so it seems like the updating of the DB schema doesn't happen on save(), but rather when the field is loaded. My guess would be that this behavior was broken when Ryan added the new custom image fields a while back.