We're experiencing a problem building templates in Word 2010 that feature Content Controls. These templates are used in conjunction with a custom system we have inherited that uses them to build reports.
These templates feature nested Content Controls thus:
<CONDITION>
<IF>{xpath}</IF>
<THEN>
{rich text}
</THEN>
</CONDITION>
The IF is used to determine whether a condition specified via an {xpath} is true or false. If it is true the content contained within the THEN control is then used.
The odd thing is there doesn't seem to be a problem building the templates. When they are saved they work fine in the custom system. However, when they are later re-opened in Word 2010, the {rich text} that was suppose to appear in the THEN Content Control is replaced with the {xpath} from the IF Content Control thus:
<CONDITION>
<IF>{xpath}</IF>
<THEN>
{xpath}
</THEN>
</CONDITION>
As the templates work with the system it seems like this corruption occurs at the point where they are re-loaded into Word 2010. As such, it seems like the first time we'll get to know about this corruption is when someone reloads the template to make further alterations, days, weeks or many months later. By which time we may have forgotten what should be there and lost an awful lot of work.
Can anyone explain why this corruption might be happening?
I've looked on the internet for an answer but found nothing.
It sounds like there is a mistake in your code causing malformed XML. When opened, Word tries to interpret the malformed XML and as a result you are ending up with undesired results.
Related
I have a large set of XSLs that we recently went through and implemented a shared XSL template with common bits. We included an xsl:include in all the main XSLs now to pull these in. We had no issues at first until we started to make changes to the shared XSL.
For information, the whole system is web based, calling queries to dynamically format documents in the database given different XSLs through XSL FO and RenderX.
The main transform is:
let $fo := util:expand(transform:transform($articles, doc("/db/Customer/data/edit/xsl/Custbatch.xsl"), $parameters))
That XSL (Custbatch.xsl) has:
<xsl:include href="Custshared.v1.xsl"/>
If we make an edit to "Custshared.v1.xsl" is not reflected in the result because it is obvious that "Custshared.v1.xsl" is being cached and used. We know this because as you can see the name now includes "v1". If we make a change and change all the references say from v1 to v2, it all works. But this seems a bit ridiculous as that means we have to change the 18 XSLs that include this XSL or do something silly like restart the database.
So, what am I missing in the setup or controller.xql (which has the following on all not matched paths), to get things not to cache. I assume that is all internal so this setting likely does not matter. Is there some other setting in the config that does?
<dispatch xmlns="http://exist.sourceforge.net/NS/exist">
<cache-control cache="no"/>
</dispatch>
In reading the document here: http://exist-db.org/exist/apps/doc/xsl-transform.xml, it states:
"The stylesheet will be compiled into a template using the standard Java APIs (javax.xml.transform). The template is shared between all instances of the function and will only be reloaded if modified since its last invocation."
However, if I change an included XSL, it is not being used.
Update #1
I even went as far as creating a query that returns the XSL that is included, then I use:
<xsl:include href="http://localhost/get-include-xsl.xq"/>
This does work as formatting is not broken, but changing the underlying XSL yields the same result. So even that Xquery result is cached.
Update #2
And yes, through some simple test all is proven.
If I make any change to the root template (like add a meaningless space) and run, it does include the changes made in the include. If I only change the included XSL, no changes happen.
So lacking anything else, we could always write a Xquery that basically touches all the main templates after a change is made to the include template. Seems so wrong as a workaround.
Update #3
So the workaround we are currently using is that we have an unused "variable" in the XSL (version) and when we update the shared template, we execute that query which basically updates the value in that variable. At least it's only one XQuery and maybe we should attach to a trigger.
There is a setting in $exist-db-root$/conf.xml for the XSL transformer where you can turn off caching: <transformer class="net.sf.saxon.TransformerFactoryImpl" caching="no"> (The default is 'yes')
I've launched a small website.
I have found that I'm getting errors by users and upon investigation see that the urls they are trying to use are all lowercase whereas I've declared them as camelCase.
I've no idea why these users should be trying to use all lower case (I can't imagine anyone would actually take the time to change:
www.mysite.com/myAction.do
to
www.mysite.com/myaction.do
However I can't think of anyway this would otherwise be changed. Has anyone else experienced this where:
yourAction.do in your mapping file is then attempted to be accessed by users as youraction.do ?
I'm using Struts2.3.1, sitemesh 2.4.2 - I've never heard of or encountered such a situation and would like advice on what may be causing it if any of you have encountered the same or similar.
Are there any browsers out there that remap camelCase.do to camelcase.do ? For whatever reason.
The only 'solution' I can think of (the best out of two very ugly and inelegant workarounds) is to duplicate the action mappings in struts.xml
<action name="myAction" class="myActionClass" />
<action name="myaction" class="myActionClass" /> //added extra but what a 'dumb' solution
Edit:
Is is possible to do the same with methods?
So that:
myAction!clear.do
will still be correctly mapped with the URL:
myaction!clEAr.do
?
I notice from re-reading my error logs that it's the 'wrong case' method in the ULR which is causing most errors.
You can use regex pattern matcher with (?i) to "embed" the matching flag(s) in the regex body. For example
<constant name="struts.patternMatcher" value="regex" />
<action name="{(?i)myaction}" class="myActionClass" />
I'm not necessarily sure about this but it seems there's something strange going on with umlauts, accented characters and such on Blade templates with Laravel 5.1.
I was banging my head on the wall with a string that ended in an ä-letter which I really, really couldn't get decoded with html_entity_decode no matter what I tried.
Here's what I had in my Blade template file as I was going mad:
{{ html_entity_decode('just-another-string-ä') }}
Now, when I render the template in a browser window I obviously get:
just-another-string-ä
But in the source I have the following:
just-another-string-äauml;
Which in my understanding does not stand for the string that I had given in the blade template.
...several minutes pass by...
After a while I changed the string to:
just-another-string-ä-test
And as a source-code result I get:
just-another-string-ä-test
Which indeed is much easily decoded than the "almost-double-auml" I got with the first string. In addition to the final letter/word replace I also noticed that things work as expected when I enter a line break in the Blade template after the line.
{{ html_entity_decode('just-another-string-ä') }}
{{-- erase this comment --}}
And everything is in order in the source code:
just-another-string-ä
Have I completely missed something here or does this smell like a bug?
Okay I've found the problem, though not really much of a solution.
After looking into this I found that it's not a Blade issue. Neither is it PHP or Apache - it's your browser.
For example, just create yourself an HTML file with the following contents:
this-is-a-string-ä
For me (at least in Chrome, I haven't tested other browsers), this will produce the same issues as you are seeing. If you have no trailing newline, view source will break, but if you do have one, it's fine.
So the solution is simple, enable the "blank newline at end of file" setting in your text editor. You should really have this turned on anyway, for example diffs work a touch better with a blank line at the end of a file (they don't see a difference where there is none), which means, by extension, version control systems like Git handle them a bit better. And it doesn't really hurt to have this enabled that I've ever found.
I would imagine that this is almost certainly a known issue, but I haven't looked into Chrome issue tracker or anything. Feel free to do so though, if you do want to get to the bottom of it. I'd be interested to know :)
A long time ago I first setup a website in Umbraco. This seemed to be working fine.
I have now come back to it about a year later, and was initially getting the following error when selecting a Document Type (any document type in the Settings tab):
A bit weird, because earlier I didn't have this issue, but fine. I do what it says, and add <identity impersonate="true"/> to the <system.web> node in web.config.
While it does fix the initial issue, I now have the following on all document types:
When trying to create a new Document Type, I get the same kind of error, but then the ReturnUrl part is ReturnUrl=/umbraco/create.aspx?nodeId=init&nodeType=inittemplates&nodeName=Templates&rnd=20.2&rndo=21.2&nodeId=init&nodeType=inittemplates&nodeName=Templates&rnd=20.2&rndo=21.2' - but only if I tick the box 'Create template for this item'. The same happens when I try and create a Template.
After Googleing I came up with this: our.umbraco post with similar issue. One (unconfirmed) solution is that there's an illegal name in a document type/ template - but I haven't changed anything, and might be fixed by going into the database.
I did check the /masterpages folder, the only 'strange' characters in there are - and _.
In my Document Types I have on named 'Textpage (Two col)' and another named 'News & Events list'. I'm a bit hesitant to just delete them, since I don't have enough Umbraco knoledge to be sure this will fix my issue...
Is there any known solution for this, or will I also have to go into the database (and if so, whereabouts?)
I'm running Umbraco 4.7.2, assembly version 1.0.4500.21031.
I've hosted this site with GoDaddy.com - I don't know if that would be relevant.
[Update 1]
As per Tom Maton's comment:
The requirepermissions should be set to false, and have been.
in Appsettings I've set this:
<add key="umbracoUseMediumTrust" value="true" />
And I've added Trusted_Connection=yes to the connectionstring.
the problem remains.
[Update 2]
Tried the solution amelvin provided, but no dice. Doctypes and templates still give the error. I'm getting more certain it's some security issues. Which folder would correspond to the Templates? Would that be the masterpages folder? If so, what kind of permissions does that one need?
It could be that you don't have full trust on your Go Daddy environment?
Check this post out http://our.umbraco.org/forum/getting-started/installing-umbraco/17856-Umbraco-on-GoDaddy-Shared-Hosting
Could help resolve your issue.
The error could be a knock on from permissions errors as yet unsolved.
But the error is thrown if the content page does not have a template assigned or if Umbraco thinks it doesn't have a template. If absolutely nothing has changed to the site then it could be that the umbraco.config file has somehow got corrupted (it will contain all the doctype/template cross reference info). This can be fixed by right clicking on the top 'content' node and choose 'republish entire website'.
Secondly navigate to the settings | document types (if you can now) and check the templates dropdown on the first tab of the appropriate document type. If its set to 'please select' then this error will get thrown when any page tries to render without a valid template assigned. If a default template is assigned - then go to that template and re-publish it - Umbraco may have lost it.
If this does not work then check if the template is assigned properly. Go to the same place in the content tree as the problem page and try to add a node with the desired doctype. If no choices are offered then it could be that the parent tab no longer allows the correct doctypes as children nodes, so go back to the doctypes and check the allowed children (second tab) of the parent node.
If none of this works without odd errors being thrown then its a mystery!
Here are a list of Permissions required for Umbraco http://our.umbraco.org/wiki/reference/files-and-folders/permissions
Or you could use one of the steps below to check all the folder permissions.
http://our.umbraco.org/wiki/reference/files-and-folders/permissions/perform-permissions-check
Or install this package. http://our.umbraco.org/projects/backoffice-extensions/ugolive this will allow you to check the permissions are correctly setup.
This code:
<cfimage action="info" structName="imageInfo" source="#imagePath#">
is giving this error:
The attribute 'structName' is required for the tag. (Found:
[source, structname, action])
When I run this code in CFBuilder - everything is OK, but I must use CFEclipse.
What should I do (I use CF9)?
Thank you for your answers!
Of course this problem won't prevent you from running your application on ColdFusion. It is just an IDE warning that something is wrong.
You have a few options.
Try using a lowercase N in structName. i.e. structname. ColdFusion is not case-sensitive, but Java is, and CFEclipse is a Java application.
If that does not work, then it probably means that the dictionary file that drives the code assist is not correct. You can go earch forthose XML files and update them to include that attribute.
You can use CFBuilder. I know you said you can't, but I have to question why. You know there is a free version that is just as good as CFEclipse, right?
The problem is that there's a casing glitch in that file Peter mentions. There's one reference to "structName" to define the attribute itself, and another "structname" which is in the list defining which attributes are needed for action="info". If you make them both the same, then restart Eclipse, you should be OK (that's I've needed to do to make the error indicator go away).