Cloud 5 - Fix Your… Rewrites

So, hey James, welcome back to the part two of the Fix Your series. In this case, we’re going to do Fix Your Rewrites. So let me jump right into it. What is the most common rewrite that AEM developers use? Hey Darren, it’s great to see you as always. And you know, without a doubt the removal of the slash content slash site name from the requested URL is the most common one that we see. In fact, it’s so common, it’s now in the default AEM archetype. A close second is using rewrites for vanity URLs and redirects for pages that have been bookmarked and now are moved to a new location, as you can see below. It should be noted that mod rewrite is not an Adobe product, but it’s probably the most used module used by the Apache web server. This means that there’s lots of content on the web for finding documentation and tools for doing that development. I know that mod rewrite is a very powerful tool, which means there are probably some things that can cause some issues in your AEM deployments. What are some of the common gotchas? Oh yeah, that’s a really good point Darren. And the number one issue that we see is when the rewrite rules you create change the cache invalidation requests. The default invalidation paths are dispatcher invalidate dot cache and should remain untouched if you want publish activations to invalidate those dispatcher path. Now number two applies specifically to cloud service deployment when your rewrite changes some of the default URLs that cloud manager uses to validate the health of your environment. You can use some of the online HT access tools to debug and validate these things before going to production. Cool, well you mentioned before that many people use rewrites to handle vanity and redirects. What are some of the tips you can provide to provide that capability? Yeah, no great question Darren. By example, let’s say you have a landing page that’s buried somewhere in that site hierarchy and marketing wants to provide access to that page on some marketing materials and you don’t want to have people hand enter a long URL that might be prone to typos or fat fingering. There are really a couple options. You can use a variety URL feature that AEM provides. It’s easy to use by marketers and can be implemented really, really quickly. It does however have some downsides. Depending on the URL you come up with, it might not be cacheable adding an unnecessary load. Plus if you use these extensively, things can quickly become unmanageable in addition to performance problems. Honestly, my favorite option is just to use mod rewrite to handle things like this, this rewrite rule that you see here. And again, in this case we’re using the contact us, but it basically takes a path like contact us that you see here and redirects to the HTML page. And let’s look carefully. You can see some of the flags that are in use here. NC means that it’s case insensitive and that R is the type of redirect you want to be sent. Another common example is mapping the favicon to another location. So here’s a rewrite rule that does exactly that. And this rule matches the entire requested URI from the caret to the dollar sign. The flags used here are the same except for the PT flag, which designates this as a pass through rule, which preserves the original requested URL. Well, cool. Are there any tools that can help test out these rewrites before deploying? Oh yeah, there are a lot of different tools that are available online for testing out rewrites and regular expressions. I don’t really want to recommend any one over the other, but most are really good at finding obvious errors. We’ll post some tools below that you can use to test your rules out. Once you have the rules sorted out, you can use the AEM SDK supply dispatcher tools to try them out with a live system. Now we’ve covered these tools in past episodes that you can reference to get you started. Yeah, great questions Darren and thank you. Thank you James.