kraftner

I don't get it. What do you mean?

@MarkKaplun Yeah, for quite some time already

Since FF57 I don't really see that any more.

Stay with Firefox. Yes the issue @fuxia linked isn't nice, and it wasn't the first one. But it's still way better than anything else if you ask me. (Closed source or owned by Google)

Do you have xdebug or some other debugger in your setup? You can have a look into /wp-includes/l10n.php

But Robin doesn't generally seem to care about doing it the WP way, so... ;)

Technically you can, it is just really, really bad practice and breaks the parser for pot files

Oh, one more idea. You probably load the translation on the plugins_loaded hook. When do you call __()? Maybe you are too early?

Okay sorry, I'm out of ideas without seeing it and I should get back to my work now. But maybe someone else has an idea, this should work.

You do have the site/user language set to german in your case, right?

Does it work if you set it?

With the correct text domain as defined in the plugin header? developer.wordpress.org/plugins/internationalization/…

This: developer.wordpress.org/plugins/internationalization/…

I don't see anything about loading the translation in your question.

Have a look at the handbook: developer.wordpress.org/plugins/internationalization/…

And then you'll need Twig helpers for all i18n functions, not just __

Then you need to load that file.

Okay first you need to save it with e.g. Poedit so you get *.po and *.mo files.

You mean 1 or 2?

Yes, just like PHP originally meant "Personal Home Page Tools" and wasn't meant for anything it does nowadays. Also if you think WP is unfit for the project you shouldn't use it and explain that to the client. But I won't get into that discussion. Let's get back to your actual issue at hand.

But hey, who am I to tell you what to do. ;)

If you want the UI of WP but want to have your own routing, templating and so on I'd recommend looking into the REST API WP offers. Or directly work with the DB. Or just don't use WP at all. I think what you're doing gets you the worst of both worlds.

As already said, even if you abort the routing you're still loading most of WP. Also I personally wouldn't feel comfortable selling something that only masquerades as WP if that is what the client requested. What would you say if you ordered a Symfony application and then what you get is something where the only Symfony thing is a Proxy that forwards all requests to a binary because I feel more comfortable writing Go?

I mean launching WP and then using nothing of it is quite a waste. You're site/application will be tremendously slower if it needs to init WP on each request. WP doesn't do any lazyloading so it always initializes the whole thing even if you only use the user part.

Okay, then why are you using WP at all instead of building a plain Symfony application?

3. As you have experienced a lot of the tooling also doesn't play to well with twig. For example various tools parse templates to extract strings for i18n which they won't detect in Twig unless you roll your own solution as well.

2.Then comes interoperability with Plugins and the wider WP ecosystem. E.g. by using Twig you are most probably bypassing the WP template hierarchy developer.wordpress.org/themes/basics/template-hierarchy which will cause all kind of compatibility issues with 3rd party code/plugins.

This isn't worth the hassle if you ask me.

So you can't easily run them before you're in the template. So you need a lot of Twig helpers (like the one you created) that pierce through the abstraction Twig is made to offer. Which kills all but one advantage over PHP templates: You might just like the format/style of Twig.

1. If you are using Twig to completely separate "Controllers" that prepare data and Twig really only assembles that this practically not doable with WP. A lot of WP core functions behave differently depending on when you call them. Some also shouldn't be run multiple times. (Which e.g. practically kills template inheritance in Twig)

That too. Generally I investigated and gave up on the idea. But let me elaborate:

Hi. I meant what you just did. :)

Basically I agree. Thing is that Gravatars e.g. are also used for WC attendee pages where people might not expect this behaviour. (I actually once wondered if that could be made into a nice "check if anyone in my address book is coming to the WC" app.) Anyway, there really are way worse things. Every page that includes Google Analytics/Fonts/CDN JS is hurting peoples privacy way more. So I don't share the overall excitement of Mark.

@MarkKaplun It's more complex than this. And I agree with Tom that I doubt Automattic is intentionally doing something nefarious here. It's just really risky to change something as ubiquitous as Gravatars. Here is an interesting read that also shows that just changing the hashing doesn't really solve everything: wordfence.com/blog/2016/12/…

Did you actually read the link I sent you?

That is only one part of it. All your internal links, attachments and anything else referencing the URL is still broken.

@MarkKaplun Automate it and you're good.

@R1ddler Because the database needs to be changed to the new URL: codex.wordpress.org/…

Taxonomies are meant exactly for that: Grouping things.

As I said, the term approach is good.

Well just add more custom_listuser meta with ids.

But then you can't do things like easily count how many people have a certain book on their list. Which you can do with the term approach.

If all you want to do is display that list you could also just store an array of CPT-IDs in a user meta field.

It really depends on what you want to do. (Surprise, not like it's always like that... ;) )

That should be fine.

Kind of, but I guess your question will be about something in relation to the publishing process which I don't do myself...