Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Textpack not populating public event #79

Open
jools-r opened this issue Dec 8, 2021 · 3 comments
Open

Textpack not populating public event #79

jools-r opened this issue Dec 8, 2021 · 3 comments

Comments

@jools-r
Copy link
Member

jools-r commented Dec 8, 2021

Am testing with Textpattern 4.9.0-dev (fafab03ecb966e0277ccc7affff5b096) and the current (4c03614) version of com_connect.

On the public front-end I see the gTxt strings and in the database, I see the owner set to com_connect but an empty event column. If I manually set that to public the correct language strings show on the front end.

@Bloke Bloke closed this as completed in 94250ef Dec 8, 2021
@jools-r
Copy link
Member Author

jools-r commented Dec 8, 2021

Thanks for adding that. Just one thing: might I/this have inadvertently affected how gTxt strings are passed through in the email body? I only saw it flash by in testing today and don't want to bombard the client with more contact form test mails, but it looked as if the strings were not being replaced in the email body. Perhaps a false alarm or do you think that setting “public" might have affected that?

@Bloke
Copy link
Member

Bloke commented Dec 8, 2021

Ack, yeah, some of them will probably need to be [Common]. Good catch.

Off the top of my head, anything that's designated as a default 'label' for any of the tags might be affected if you don't override those labels via an attribute, since they'll be used in the email body I think.

So , com_connect_text, com_connect_name, com_connect_email, com_connect_option, etc...

@Bloke Bloke reopened this Dec 8, 2021
@Bloke
Copy link
Member

Bloke commented Dec 8, 2021

Hmmm, if you get a chance and can repeat the untranslated strings thing, please let me know how. I removed the label attribute from a few fields in my contact form (an email field and a select list) and they came through as:

Email: <address>
Option: <the selected value>

capitalised, i.e. translated even though they're public. That was kind of expected/unexpected, but I guess it's still public code that's executing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants