-
Notifications
You must be signed in to change notification settings - Fork 135
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
Media in ACF WYWIWYG field is serving the front end path instead of the backend path #1956
Comments
Hey @mmgyshoaf, thanks for reporting this issue. Do you have any other plugins active on your site when experiencing this behavior? Any additional info you may have with that will help us reproduce this issue. |
@josephfusco thanks for looking into this. This is a multisite setup, here are the plugins that are enabled network wide:
Interestingly, we have two sites where we are seeing the images use the correct path on one, but not the other. Same codebase, and I've double-checked that the Faust and GraphQL settings all appear to be the same. |
@mmgyshoaf can you share the query(s) you are running and their results? both with and without the option in Faust checked? can you also share a .zip of your ACF Field Group exported as JSON so we can reproduce exactly? |
Hey @mmgyshoaf, I am unable to reproduce this issue locally, but here is what I've tried so far:
Here is the ACF export I used that adds a single WYSIWYG field to each post: Here is the query I used to see the images in the WYSIWYG field: {
posts {
nodes {
__typename
wysiwyg {
__typename
myContent
}
}
}
} Here is an example response showing all images in the WYSIWYG using the WordPress URL, with the same response both as an authenticated user and public user.
Providing the above would help us better assist with resolving issue you are experiencing. |
Hi @josephfusco thank you for taking a look at this issue! Here's the ACF export: acf-export.json I get the same response whether or not the Faust box is checked. FYI the cms subdomain for WordPress, and preprod is the subdomain for the frontend. Here is the query:
Response from the site where it is not working, same response whether or not the Faust option is checked or not:
On site where it is working as expected, Faust box is checked:
Faust box not checked, this site will toggle back and forth using the WordPress domain based on the box being checked:
If you have access to the WP Engine helpdesk, I have an open ticket there as well, they're replicating it in my environments. https://help.wpengine.com/hc/en-us/requests/7304303 They're the ones that suggested that I open this ticket. Thanks! |
@josephfusco ^ I don't think we tried with these settings being configured differently. This might be the missing bit of info we needed to reproduce 👀 |
FYI all the logic for src replacements are located in this filter
|
I am currently investigating this issue and I can replicate an issue with the image URL using a Local Multisite and sub-domains but I need to do further investigating here. Setup
I setup a WYSIWYG for pages with the WPGraphQL ACF name "summary". IssueThe issue I am seeing is related to the HTTP scheme as shown below that for some reason the image inserted contained both a HTTP and HTTPS URL so we are not replacing both. GraphQL query is
Response with
Response with
Configuration for Faust has the front-end URL set as |
Description
I updated the setting here to "Use the WordPress domain for media URLs in post content", existing content that uses ACF WYSIWYG field is still serving the image with the front end URL instead of the WordPress domain. Screenshot of my settings:
Steps to reproduce
Additional context
This is a multisite environment. We updated this setting for all sites. Some sites will now display the cms path for new content, other sites are still rewriting to the FE path.
@faustwp/core Version
3.0.0
@faustwp/cli Version
3.0.0
FaustWP Plugin Version
1.4.1
WordPress Version
6.6.2
Additional environment details
No response
Please confirm that you have searched existing issues in the repo.
The text was updated successfully, but these errors were encountered: