According to Microsoft's Office add-in documentation. the Requirements element in the manifest specifies "... the minimum set of JavaScript API for Office requirements that your Office Add-in needs to activate."
I can't figure out the correct place to put that element. The above-linked documentation says Requirements is a child of OfficeApp, but the Seller Dashboard and the manifest validator both say that is incorrect:
Details: The element 'OfficeApp' in namespace
'http://schemas.microsoft.com/office/appforoffice/1.1' has invalid
child element 'Requirements' in namespace
'http://schemas.microsoft.com/office/appforoffice/1.1'. List of
possible elements expected: any element in namespace
'http://www.w3.org/2000/09/xmldsig#'.
All the docs I've read, SO questions, etc., only include snippets like:
<Requirements>
<Sets DefaultMinVersion="1.1">
<Set name="WordApi" />
<Set name="ExcelApi" />
</Sets>
</Requirements>
But those snippets do not say under what parent to use <Requirements>.
Where does Requirements go in an Office add-in manifest file?
The <Requirements> element comes after <Hosts> and before <DefaultSettings>.
I got this by noting that:
<Hosts> is the last element in the sequence of <OfficeApp> children (schema link)
<Requirements> is the first element in a subsequently-defined extension to` (schema link)
XML schema <extension> elements always append to the base element being extended (see, e.g., this SO answer)
I tested this by putting <Requirements> in various places in the file. Putting <Requirements> after <Hosts> and before <DefaultSettings> was the only placement that worked. (Putting <Requirements> as the first child did not work.)
Thanks to user Rick Kirkham, whose now-deleted answer pointed me to the schema definition.
Related
In my manifest file I have the following code:
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" MinVersion="1.2"/>
</Sets>
</Requirements>
But it doesn't work, the manifest file is not valid.
The <Requirements> element has to be between the <Hosts> and <DefaultSettings> elements within a parent <OfficeApp> element.
We have not done a good job of documenting the required sequence. In the meantime, you can see the OfficeAppManifestV1_1.
I'm trying to leverage Import/Export module to import taxonomies and taxonomy terms like so
<Orchard>
<Data>
<Taxonomy Id="/Identifier=Product-Categories" Status="Published">
<AutoroutePart Alias="eshop/categories" UseCustomPattern="false" />
<IdentityPart Identifier="Product-Categories" />
<TitlePart Title="Product Categories" />
<TaxonomyPart TermTypeName="ProductCategoriesTerm" />
</Taxonomy>
<ProductCategoriesTerm Id="/Identifier=Category-1" Status="Published">
<AutoroutePart UseCustomPattern="false" />
<IdentityPart Identifier="Category-1" />
<TitlePart Title="Test category" />
<TermPart Count="0" Selectable="true" Weight="1" TaxonomyId="/Identifier=Product-Categories" Path="" />
</ProductCategoriesTerm>
</Data>
</Orchard>
ProductCategoriesTerm when created through dashboard has default pattern
{Content.Container.Path}/{Content.Slug} ### my-taxonomy/my-term/sub-term
but importing terms makes them to use just {Content.Slug} ... How do I instruct AutoroutePart to use the default pattern? Tried UseCustomPattern="false" or exclude AutoroutePart with no effect it's just test-category instead of eshop/categories/test-category and won't regenerate even if if I set AutouroutePart to automatically regenerate when editing content and disable custom patterns and it won't revert to default pattern even if I try to publish it through dashboard.
Also it's mandatory to include "Count" for the TermPart when importing, does it affect anything? Sounds like something that should be dynamic and relevant only with export.
When importing taxonomy terms (and I guess any other part that has a container) it's necessary to specify Container for the common part. Without it Container for the part is null and therefore can't resolve {Content.Container.Path} in the alias pattern.
<CommonPart Container="/Identifier=Product-Categories" />
Or if it's nested term then Container is the parent term.
My XML (simplified) is like this:
<Actions>
<Action Id="1">
</Action>
<Action Id="2">
<DoSomething>
<ActionRef ActionId="1" /> <!-- valid -->
</DoSomething>
</Action>
</Actions>
The ActionId attribute value references the Id attribute value of the Action element. I've already set up a foreign key constraint in the XSD, and it works correctly.
I want to prevent self-referencing values in the foreign field, like this:
<Actions>
<Action Id="1">
</Action>
<Action Id="2">
<DoSomething>
<ActionRef ActionId="2" /> <!-- invalid -->
</DoSomething>
</Action>
</Actions>
Of course, this can easily be done within the application that processes the XML, and I'll fall back on that if what I'm asking for isn't possible, but I'd much rather have this done automatically by the validation process.
I tried adding [not(#ActionId = ../#Id)] to the foreign key selector XPath query, but that isn't valid in that context (nor am I sure it's correct either). Other than that, I have no idea what else to try, and it doesn't look like many people on the internets even set up foreign key relationships in their XSDs, let alone prevent this kind of situation (I found nothing on this exact topic).
It cannot be done - the selector syntax for XSD constraints is very limited. Other alternatives may include Schematron, which should be reasonable to integrate assuming your runtime has access to an XSLT processor. The effort could pay off is you decide to add more validation rules separate from the code of the application that processes the XML.
Is it possible to disable a <remove name="left"> statement defined in a default layout .xml file, from the local.xml file?
For example, in the checkout.xml in the <checkout_cart_index> section, the statement <remove name="left"/> is defined there, but can you disable that line from the local.xml file, so you still see the left menu on the checkout page?
By default Magento doesn't provide an <unremove /> tag for local.xml. However, the Layout system contains the right events, such that you can implement this yourself. And by "yourself", I mean I've created an experimental extension that adds such a tag. Feedback is welcome.
The two ways I do this are;
Use Alan Storm's excellent unremove plugin above.
Re insert the removed block in local.xml with a new name attribute but the same alias or 'as' attribute.
The name attribute needs to be different because Magento's <remove name="foo" /> is global - it removes all instances of <block name="foo" /> even if they are added after the remove instruction. To re add the left column, for example;
<reference name="root">
<block name="left.2" as="left" type="core/text_list">
<!-- New left column is empty, so you'll need to add your left-column blocks into it here. -->
</block>
</reference>
name="left.2" means the remove action won't kill this block, as="left" means that it will still be inserted into your template via <?php echo $this->getChildHtml('left') ?>.
Unfortunately, your newly inserted left column is empty. So you'd have to re insert any blocks in there that you want to show as well. Making Alan Storm's plugin all the more useful, I think.
When a block is removed it is not destroyed, only ignored. You might be able to 're-enable' it with:
<checkout_cart_index>
<reference name="root">
<action method="append"><block>left</block></action>
</reference>
</checkout_cart_index>
I've never used this myself and wouldn't want to, if you are making a custom theme then copy the base layout files and edit them directly just as the other answers recommend.
your answer is not to disable the removal but to add it again in your local.xml
Rather than trying to reconstruct the entire set of blocks, comment the remove inside the original XML. This will be less of a maintenance headache than trying to reconstruct the blocks and worrying about precedence of the XML files, etc.
Turn this
<remove name="left" />
Into
<!-- disabling remove because X -->
<!-- <remove name="left" /> -->
I've got a customized clean-up and it's almost 'there'.
However, R# appears to want to sort the member methods, but at least it does not appear to be alphabetically.
Is there a way to force that sorting?
Customizing the layout can indeed be accomplished with Resharper. Go to:
Resharper->Options->Languages->C#->Formatting Style->Type Members Layout
ReSharper 2017
Resharper -> Options-> Code Editing -> C# -> File Layout -> Interface Implementations/All Other Members
and uncheck the "Use Default Patterns" option.
Now you'll want to edit the xml in the "Custom Patterns" box. I'd recommend copying it out to an editor that can properly hi-light the xml (notepad++ or visual studio should work fine).
Now, find the section near the bottom:
<!--all other members-->
<Entry/>
and change it to:
<!--all other members-->
<Entry>
<Match>
<Kind Is="method"/>
</Match>
<Sort>
<Name/>
</Sort>
</Entry>
Now, make sure that your cleanup profile has "Reorder type members", and then right click on the filename in solution explorer and do "Cleanup code...". I've just tried this myself and it does order the methods alphabetically.
If you want to also sort by access type, you can add this under the <Sort> element:
<Access Order="public protected internal private" />
Here's an article to learn more.
Resharper->Options->Languages->C#->File Layout
Select "All other members" and select "Sort by name" (highlighted in bottom right of pic)
In the XML file layout you have to add the element Entry.SortBy
For example in All other members:
<Entry DisplayName="All other members">
<Entry.SortBy>
<Name />
</Entry.SortBy>
</Entry>
The problem with the 9.2 is that when the Entry.SortBy is missing from XML the selected value from the designer is not saved.