This article is for Account Owners and Project Managers using the Global Delivery Network.
Important Disclaimer
The Advanced GDN Rule editor is designed for developers who have in-depth knowledge of your source code, site design, and the Global Delivery Network. Changes made using this tool can break functions of your translated sites, and in some cases prevent the translated sites from functioning in entirety. We recommend that you instead markup your source code using our GDN integration tags or configuration rules. If there are cases where this is not possible, contact your Customer Success Manager to discuss if this tool is right for you.
Rewrites allow you to alter the contents of a file or page, either before or after it has been parsed by the GDN. Similar to find and replace, you must specify a string or regex pattern to find and a string to replace it with.
To Create an Advance Rewrite
- From your GDN project, click the gear icon > Project Settings > Advanced GDN Rewrite
- Click the + New Rewrite button
- Choose your rewrite type from the dropdown menu
- Choose the domain and languages this should apply to
- Insert a rewrite condition, if applicable
- In the Rewrite search field, enter the text/URL you want changed
- In the Rewrite Replace field, enter the text/URL you want the search changed to
- Add a comment
- Click Save to create your rule or Cancel to start over
View Rewrite History
You can view the history of each rewrite by clicking the ellipses under Actions > View History. This shows the complete change history for a rewrite, including who made the changes and when. The history also shows the differences between the current and previous versions of the same rewrite.
Click the downward arrow of each history item to view the rewrite details.
Restore Rule
For each previous version of a rewrite, there is now a "Restore" button that allows you to bring back that iteration of the rule configuration. To restore an older rewrite, click the downward arrow > Restore
Use Case
Rewrites can be applied either before it has been parsed by the GDN (pre_replace) or after translations have been applied (replace).
A content swap is a form of a rewrite that can be done without access to advanced rules.
Rewrites can be applied at the following 4 points:
PRE_REPLACE_REQUEST_BEFORE_PARSING
Replaces matched content in all file types BEFORE it is parsed by the GDN. This rewrite should be used if you want to change how content appears to the GDN.
For example, you have language-specific content that you want translated instead of the existing source content. A pre_replace rewrite will change the content before it is parsed by the GDN, effectively stopping the original source content from being ingested at all.
PRE_REPLACE_HTML_BEFORE_PARSING
This rule functions similarly to PRE_REPLACE_REQUEST_BEFORE_PARSING, but will only affect HTML content. Any content in JavaScript, JSON, XML, etc. will NOT be affected by the rewrite unless it is specifically ingested as HTML via an existing rule.
REPLACE_REQUEST_AFTER_TRANSLATION
Replaces matched content in all file types AFTER translations have been applied by the GDN. This rewrite should be used if you want to change how content appears to the end-user, after the GDN has completed parsing and translations.
For example, you have added a class or comment for parsing purposes that you do not want displayed to the end user. Once translations have been complete, you can use a rewrite to remove these lines. In contrast, using a pre-replace would mean that the GDN would not see these classes/comments and revert to its default behavior.
REPLACE_HTML_AFTER_TRANSLATION
This rule functions similarly to REPLACE_REQUEST_AFTER_TRANSLATION, but will only affect HTML content. Any content in JavaScript, JSON, XML, etc. will NOT be affected by the rewrite unless it is specifically ingested as HTML via an existing rule.
replace_request_body
This rule ensures API requests are sent in the language of the API. This allows you to display translated strings on your website while ensuring any API requests match the language of your source code.
Risks
Poorly or incorrectly written rewrites can have adverse effects on your GDN sites. Issues can include incorrect parsing of content (filling authorization queue with wrong strings), broken functionality or performance loss. It is ALWAYS recommended that you test your GDN rewrites on a staging site first.
Best Practices
Testing for rewrites should always be conducted on a non-production environment first. When modifying an existing rewrite, you should always create a copy of it first. You can then disable the first rewrite to test your new rule.
Rewrites are NOT backed up and cannot be restored to a previous version.
Rewrites can be limited to a single domain by using the Domain dropdown option within the advanced rules interface. After testing, the rewrite can be applied to a production environment by changing the domain.
Rewrites can also be limited to specific URIs by specifying 'uri:' in the Rewrite Condition field. For example, if you only want the rewrite to apply to blog pages, you can use the following condition:
uri:/blog/
When using a regex pattern for the rewrite search, make sure you tick the 'Is regex' option. Please note that poorly written regex patterns can have a negative performance impact on your localized sites.