After a deploy to our Acceptance environment, templates in sitecore seem to be broken. We have installed them back with an item package from a working environment and did a revert on the /sitecore/templates/system tree.
We didn't notice any difficulties here, but when we try to edit with a rich text editor, we see the raw values. Even a tree list is rendered as a single line text field.
Next to that, the /sitecore/templates/system/templates/template item does not contain any fields.
Since we are on an acceptance environment, we cannot revert the entire database in case of data loss.
Do not think I entirely understand your issue, can you please be more specific and give us more details? You say templates are broken, but in what way exactly?Can you try reproducing that to ensure it happens again?
If you see everything as a text value, that happens because of you have Raw values in View tab switch on.
Related
I have a strange issue whereby when I edit a rich text field in the experience editor and save the page, it takes me to the layout not found page.
When switching back to the content editor, I can see that final layout has been completely wiped (the shared remains intact). I've noticed that if I change to the shared layout within the experience editor (via the presentation tab) and perform the same edit - it works fine.
What would cause the final layout to be wiped?
I've noticed that this can be caused by having Final Renderings set on a template's standard values. Currently I can't think of a reason to do this but I can see how it's very easy to accidentally edit a standard values item in the experience editor in the wrong mode.
It's easy to reset presentation details back to standard values in Sitecore, but to my knowledge you can't reset just the final renderings. To avoid having to go through each failing template and manually reset and re-add all the added renderings I've found an easy way to fix it if you have TDS (or similar) installed.
Search for __Final in the /Sitecore/templates folder in the file system.
Delete all the instances of this __Final Renderings field (From the '----field----' line until the next one).
Sync with Sitecore.
Not really a fix to the issue, but when I had to fix >20 templates where this was happening it saved me a lot of time and thought it was worth a share.
we faced very specific scenario in our Sitecore enviroment. In our Sitecore we have a item, lets call it "Promotion". Promotion was using "End date" field that was shared.
On our dev instance we "unshared" the field. Which naturally triggers the background process that changes the items to use field in unshared mode.
Similar process is described here: http://sitecoreblog.alexshyba.com/2011/10/changing-field-sharing-settings-in.html
So then we packaged and installed change of "unsharing field" on production "master" database. As I assume during installation the background process of "updating the items" has not been triggered. Which now behaves in the way, that "unshared" field on our production master database cannot be saved. Cahnges of value after clicking save are "vanishing". I am sure they are now being saved in some language agnostic mode.
Of course simple fix for that is to "share" it back and "unshare" it again. However when we tried to do this experiment on copy of our enviroment and we noticed all the values were lost. As the items from mentioned template are heavily used, we cannot really afford loosing those values.
Any ideas?
I would go "database digging". Sitecore stores these field values in their respective databases inside the "SharedFields", "VersionedFields" and "UnversionedFields" tables.
Assuming you shut off your Sitecore instances (this is important), you should be able to SELECT the data out of the wrong table, and INSERT it into the correct one.
(you need to look for items where FieldId matches the field you are having trouble with)
From what you've described, I don't believe Sitecore has removed any data on your production environment (yet).
So the solution we came up to, was to use Sitecore Rocks tool. We exported all the Items containing the fields before changing the field to "Share". The query was more or less like that:
SELECT ##ID, ##Start Date#, ##End Date# FROM //*[##templateid='{993DC54F-6724-46C3-B8D2-3EE13F15366A}']
It gave us proper values at that point, even though to items were pointing to the SharedFields table. We just simply converted the result of this query (around 9000 rows) in Excel to Sitecore Rocks update query -
UPDATE SET ##Start Date#='20120531T000000',##End Date#='20120614T000000' FROM //* [##ID='{E3FD9819-3DBD-4FAA-8DEF-FEF2A6272723}'];
After prepared this migrations script, we shared the appropriate field and apply the script of 9000 updates queries through Sitecore Rocks. We need to to exactly the same on Live database. Everything went pretty smooth.
The same approach could be easily done with the database I believe, however this solution was better for us, because of non-technical reasons (security policies etc.). Anyway Sitecore Rocks rocks!
I have a search field, which lets the user search books (filters records, which are retrieved with ember-data).
I have found that any access the store from the results computed property within my component (see jsbin) makes the typing into the search field very slow (noticeable on my PC, and terrible on smartphone).
Here is a screenshot of the Timeline pane when typing a search query. The displayed part show that every keypress causes A LOT of layout (the search field seems to rerendered on every keypress). I also provide the exported timeline which you can load into your dev tools as explained here
I have tried to recreate the issue in a jsfiddle, but it seems to work just fine. The difference might be that in the jsbin I am using fixtures, while in my app I retrieve data from a real API.
I don't understand what is causing this behavior. It may be hard to come to any conclusion from the data I can provide, but does anyone have any ideas? Has anyone experienced similar performance issues?
Update 2014-03-01
I should note that the performance hit only happens if the results computed property contains a call to the store. If I replace it with any other thing (like just returning [], or some random async method -- like $.get) it not display this performance hit.
Additionally, I should make it clear (in case you didn't read the code), that the results computed property is not called on every keypress, but only when the search is submitted.
This is not a Ember/Ember-data bug, but apparently a Google Chrome bug.
I have created a new question regarding the issue here
We've been noticing an increase in number of broken links on our sitecore website.
Some it is due to
User Training
Publishing Issues (linked page is not yet published)
Maybe content editor issues
It's been hard to verify some of these but sometimes the link might have the authoring page URL (which means someone didn't follow the SOP), sometimes they have a strange url like /shell/Content Editor/...
So we are trying to proactively fix these before the pages go live.
I had a couple ideas like writing a Handler that would look through all "Rich Text Fields" and looking for inconsistencies (like authoring server URL). Also using a crawler-type of validator could help us (http://home.snafu.de/tilman/xenulink.html#Description) but we were wondering what the community was doing to address this issue.
The "internal link checker" usually works well but doesn't detect many of this erroneous setups (as I believe it sees them as 'external links').
Your input is greatly appreciated!
If you have RichText fields and create internal links, your internal link looks like this in the HTML view: "a href="~/link.aspx?_id=EB3AD128E7BF4F3C9F3812F701D7724E&_z=z" and when you hover with your mouse over it, is show "/Sitecore/Shell/Controls/Rich Text Editor/" before the ~/link.aspx. This is normal behavior. This link is modified to a normal link during rendering of the RTE field.
However, be sure to use the Sitecore controls like to render these RTE fields and to render links. Also using sc:fld() in XSLT instead of sc:field() can create strange links because sc:fld is rendering the raw value of the field.
In all of the Sitecore projects I have been working on, I didn't have much issues with broken links.
There is a known bug with copy-pasting links from a rich text editor, where path info is appended to the link (generating the /shell/Content Editor/ stuff).
Sitecore have a fix for it here:
http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/KnownIssues%20Recommended/Copying%20and%20pasting%20link%20in%20rt%20fields%20may%20break%20the%20link.aspx
I would suggest a new Validation Action added to the workflow command before the items are finalized. Then you could actively stop them from being published and give immediate feedback. If you're not using workflows, you could add a new item level validator, but those often get ignored in my experience -- too many false positives on the existing validators.
it seems that the google doc/wiki is difficult if i code it from the zero
So, are there any kinds of api/plugin already have those code for php.
Also, how can wiki handle the parallel editing?? Say, one have update the content when the other one is updating. How can the latter one get the most updated information ????
Otherwise the updated content will be erase once the latter one submit update .
Thanks
I'm not sure about the first part of your question, but as for the parallel editing:
It seems to me that you're basically coding a CMS system. As with most CMSs (CMSii?), you're going to want every article to have two possible states: checked in or checked out. That way, you eliminate the possibility of 2 people working on the same article simultaneously.
So basically, in your database table that holds your article entries, you'd want a row called something like checked_out, which defaults to 0.
When an editor clicks to edit an article, your code first checks to make sure checked_out == 0. That way it knows you're the only one working on that particular article. Then, if it does allow you to work on the article, set checked_out to 1. When you click to save/update/whatever the article, make sure it sets checked_out back to 0.
Seems like the simplest solution to me.