I've posted this in the Our Umbraco forum (http://our.umbraco.org/forum/ourumb-dev-forum/bugs/30914-HTML-formatting-error-on-workflow-notification-emails) but would like to expand the audience as I need a quick resolution to this problem.
There appears to be an issue with the HTML used in workflow notification emails, property names are displayed but their values are not visible. The HTML content is there and if I save the source as an .htm file and view it in Firefox the values are displayed (although in the wrong location).
The HTML is generated from the sendNotification function in the umbraco.cms.businesslogic.workflow namespace, I am using Umbraco v4.7.1.1 and this problem was noticed in Outlook 2007.
Has anybody else encountered this problem?
It appears that this issue has been logged with Umbraco (http://umbraco.codeplex.com/workitem/26577) but has not been addressed.
The fix is a simple code change, for my current project I have decided to download the CMS source code and make the change myself. This works but throws up maintenance issues e.g. ensuring my change is not wiped out during a CMS upgrade.
Related
Previously working code that downloads a csv file from our site, now fails. Chrome, Safari and Edge don't display anything helpful except "Blob Blocked", but Firefox shows a stack trace;
Uncaught TypeError: Location.href setter: Access to 'blob:http://oursite.test/7e283bab-e48c-a942-928c-fae0907fdc82' from script denied.
Then a stack dump from googletagmanager
This appears to be a fault in the tagmanager code introduced in the last couple of weeks.
The fault appears in all browsers and is resolved immediately by commenting out the tag manager. The problem reported by a customer on the production system, and then found on both staging and locally. The customer advised they had used the export function successfully 2 weeks ago.
The question really is, do Google maintain a public facing issues log for things like the tag manager?
It's not about GTM as a library really, it's about poor user implementation. It's not up to Google to check for user-introduced conflicts with the rest of the site's functionality.
What you could do is go to GTM, and see what has been released in the past two weeks. Inspect things and look for anything that could interfere with the site's functionality. At the same time - do the opposite, see all the front-end changes introduced during this time frame by the web-dev team.
Things to watch for is mostly unclosured JS deployed in custom HTML tags. junior GTM implementation specialists like to use the global space, taking the global variables, often after the page is loaded, thus overwriting front-end's variables.
Sometimes, people would deploy minified unclosured code to the DOM, thus chaotically taking short var names. To the same end.
This is likely the easiest and most common way for GTM to break front-end. There definitely still are many ways to do so besides this though.
If this doesn't help, there's another easy way to debug it: make a new workspace from Default (or whatever is live), go into the preview mode and confirm that the issue still happens. Now start disabling newest created fired tags one by one and pinpoint which one causes the issue.
Let us know what it was.
Solution was to replace the previous tag manager code with the latest recommended snippet
I decided to give wp ago, thought it would save time from writing custom html, css and js.
For the most part it has, however, how the page renders in my admin page compared to live is very different.
Because it’s rendering in admin as expected I’m finding it difficult to correct the display issues.
Has anyone else experienced this? If so, how did you resolve it?
Compare the domain name in the URL when your are logged as admin to the domain name when you are live.
If you create your WP at first time in a development URL then moves to a different server it will not be able to find CSS files what causes wrong rendering.
I have some Computed Fields and in these fields, I get some HTML codes with simple_html_dom.php class from some sites. Codes works perfectly on pages, but when I try to get these fields to use in a View, Drupal gives the following error.
http://i.stack.imgur.com/W2Rhc.jpg
Anybody can help?
Even if it is not the best solution, after installing Views PHP module of Drupal, problem is slightly solved. I still get the error message on every time I try to change something, also I am having difficulties on making a change on the view, like saving and adding the same thing 5 times and got successfull, still it is a solution.
This message usually appears when you try to save the form before the ajax process has finished.
Try checking the 'network' tab on developer tools installed within Google Chrome or by using a tool similar to firebug. This will show you the request being made via ajax and should give you more information to debug.
I have implemented New UI SiteEdit in Tridion 2011 SP1. When I have created a page without components in it ,I am able to edit the page. If I am inserting the component I am not able to edit the page. Please help on this issue?
When changing a Page in New UI (Experience Manager or XPM), the page is checked-out. What you might be seeing for other users is expected behavior--other users should not be able to edit the page in the CME or within XPM.
Also, you should be restricted from editing content page for even the same user that has a different session (e.g. viewing the page from another browser).
When editing the page with the same user and session, you should be able to add multiple components. The page is checked out. Editing content on the page should be "editing components," rather than the page itself.
Let us know if you're seeing something else.
This can be a result of having an syntax error in your inline editing commands (i.e. the JSON syntax inside HTML comments). Normally you would use the OOTB building blocks that generate this for you, however, in some extreme scenarios, this syntax is written out by hand. I suspect that you may have the latter scenario. Verify your component and component field command syntax.
I add content to an article (either administrator or as content user) and I save the changes as Full HTML or Filtered HTML.
Once I run CRON,the article is marked updated and when I preview it i see plain text instead of HTML.Some sort of over writing is taking place which I am unable to figure out.Earlier I thought it was a problem with the webform module but it is not.I tried disabling the modules one by one but was not able to detect the problem.
Do you check your content under the same user ? I can hardly believe it's a time related issue. It seems more like a rights problem. Do all the relevant roles have access to the input filter Full HTML ?