Malcolm-M
Boss
Joined 15 years ago
Admin for a large UK company's social platforms including Lithium Communities, LSW and a social listening tool. Have worked in social media since helping found a community in 2010.
User Profile
User Widgets
Contributions
Re: Can We Truncate Subscription Email Post Body?
Apologies forgot it was Velocity. Wonder how the Aurora emails are generated, hopefully something a bit more straightforward. We went down the route of not including the body text by default for similar reasons. It's easy enough for power users to enable it again.Re: Can We Truncate Subscription Email Post Body?
I'll be honest I haven't worked on email templates, we had an agency overhaul them for various reasons. There is however a truncate option for Freemarker I've used in a number of components. If the body is added in as a ${} variable it might work. Built-ins for strings - Apache FreeMarker ManualRe: Dev server best practices?
For us it's essential. We like to be able to keep everything ready for very quick Stage to Production pushes so it's very rare for anything to get built in Stage which is kept as identical to production as possible. So our workflow would normally be: Build - Dev; Basic Testing - Dev; Copy - Use SDK, Studio and Community Admin (if needed) to copy Dev to Stage; Full Testing - Stage; Deploy - Push Stage to Production and make any required Community Admin changes. Khoros keep both Stage and Dev up to date, version wise, for us so it's just a case of porting any structure changes backwards along with the rare things built in Stage. This allows us to have Dev in any state we want in terms of ongoing dev work without blocking us from pushing out emergency changes like banners from Stage. Also helps in that if one developer is working on bigger changes in Dev then the other developer can make quick changes in Stage. It also means if a large piece of work is ongoing such as re-skinning the site we are not blocked from making changes to Production via Stage. Honestly the amount of work required to move changes back and forth to keep things in sync is minimal.Re: Dev server best practices?
The one tip I would have is for anyone working in Dev (or Stage) to keep a .todo file listing all the changed style, component, asset and page quilt files alongside any Studio/Community Admin config changes, etc. for each piece of work. Makes moving things back and forth a lot less prone to error as does keeping a well commented Git repository for the Dev environment.
