We have recently implemented SolrCloud with Sitecore 8.0 Update 2. All works fine and good with this setup. Then we introduced patch 449298 into the mix to enable switch on rebuild functionality. Our CM server is the only one that initiates indexing. Both CM and CD use searching functionality against SolrCloud.
All works well and fine in regards to incremental updates. But when we rebuild the indexes, the CD servers do not pick up the rebuilt indexes. They still point to the previous "primary" indexes. CM works fine without issues. When we manually switch the indexes then they work fine for CDs as well.
The only issue we ever notice is pasted below but this seems like a harmless error.
9/11/2016, 11:48:55 AM WARN OverseerCollectionProcessor OverseerCollectionProcessor.processMessage : createalias , {
OverseerCollectionProcessor.processMessage : createalias , {
"operation":"createalias",
"name":"social_messages_web_alias_secondary",
"collections":"social_messages_web_secondary"}
Is 449298 required on CDs or can we just OOTB libraries on CDs and 449298 on CM?
Any help is appreciated!
Based on the documentation on the release page in github it says the following:
Download the Sitecore.Support.449298-7.2.6.0.zip file.
Extract the archive to the Website folder of all Sitecore instances in the solution, overwrite existing files if any conflicts occur
So, i think you should apply it on all of Sitecore instances that you have in your environment, I have not tested this myself, But based on the documentation it seems thats the right way.
Related
The problem is that the source code distribution is not exactly the code that runs after installation. The installer, which runs when the site is accessed for the first time, generates a lot of code. Also, a running system stores some data in php source code (e.g. user profiles - under the /user_privileges directory) rather than in the database. So, I have the following unsatisfactory possibilities.
(1) Put the original source code under VC and edit it. In this case I have to do a fresh install and run the installer every time to see how my changes are working.
(2) Put the installed source code (after the installer has run) under VC, and edit it. In this case I have immediate feedback, but I can't use that code for new installations. I also have to exclude everything that the running system writes in the source tree from the VC.
Any suggestions?
I am working with Vtiger CRM version 6.0Beta, but any tips relevant to version 5 would help.
Thanks.
Choice 1 is appropriate. VC must always track the source code, not the products of any interpreter or processing. I feel your pain. It is so easy to tweak that Vtiger source code, and VC tends to be left by the wayside.
Get familiar with GIT. Really, it is what you want. Look here, I already did it.
Copy the original code in one branch
Copy the modified code into another branch
Make a diff or better, run git format-patch
Install (checkout) your new Version
Check the patches and apply them, if necessary.
Bonusses
Have a private and a public remote for your repo, so that you can keep track on the crumpy files in user_privileges and friends in private, but share code with others
Have an absolutely beautiful backup with daily rollback by just setting up a branch, a remote and a cronjob.
Beeing able to replicate the live situation within minutes for local development
Painfree Updates !!
I know, this is no easy task, but once done, it will make your live pretty much easier.
We are currently running Sitecore CMS 6.5 (120706) with the shared source Item Buckets module installed from here:
https://github.com/jerrong/Sitecore-Item-Buckets/tree/master/sitecorepackages/ItemBuckets%206.5%20NET_40/Final
We wish to upgrade to CMS version 7.0. I'm told that there is currently no upgrade path and to expect one in a few months. However we would prefer not to have to wait on this.
Item buckets is used only for a single section of our site. Everything else is delivered via the standard content tree.
We have tried upgrading to 6.6 first as required by the documented upgrade procedure, despite it mentioning later in the instructions that the shared source item buckets module is unfortunately unsupported for upgrade. Confirmed that this definitely does not work, we receive the error:
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.3.1.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
We also tried disabling Item Buckets by removing the .config files etc. but we had further problems, presumably because of the actual content/data template changes that were made by the Item Buckets update.
We are thinking of trying a clean install of CMS 7.0, and then migrating our custom code base, items in the content tree (including data templates, layouts, renderings, etc) with Sitecore packages to work around the issue.
Can someone validate this approach, or better still suggest a much less painful solution!?
Many Thanks
(this is not official Sitecore advice as that is still being worked on disclaimer,disclaimer!)
Some ideas that might help ..
First we need to work on the data side of things (forget front end code for a second)
You could Un-bucket your items so that they are again plain Sitecore items. You could then remove the item bucket module templates and fields as you mentioned before (by 'unbucketing' you should now have no reliance on the bucketing templates etc.)
You could also look at creating an 'anti-package' using Sitecore Rocks, either way this should give you a site closer to a site before the item buckets module.
You could then get a base/clean install of 6.5 (120706) and then compare it to your working copy 'master' database using a tool like Sitecore Courier.
Sitecore Courier - https://github.com/adoprog/Sitecore-Courier - Allows you to compare 2 versions of Sitecore DB against each other and make an update package of that difference.
This should make you an update package of all the changes that have been made to your 'master' database so that you can, in theory, install this into a fresh copy of Sitecore.
You could see how far this gets you when you install this update package, in theory then you can re-bucket your section that used the old buckets module but using the new built-in buckets.
Front-end code wise, the old item buckets modules way of accessing the search has been completely re-written as that it now uses Linq To Sitecore. Hopefully this will be easier to migrate and the buckets will still work in largely the same way (hopefully better hehe!)
Like Ruud I would be interested to hear about others techniques for doing this.
Any extra complexity could come from thing like :
1) How much customisation of the core database you have done
2) How many new field types and XAML applications you may have written
At this point, there is no good solution for this yet.
If you are actively using the module, there is no way to upgrade right now (not that I know of).
If you are not using the module at all, you can remove everything in Sitecore that has to do with ItemBuckets.
This is a manual job for now... (I've done this with success in a 6.5 environment).
To be sure you remove everything, open the item buckets installation package (the ZIP file) to see what items are installed and manually remove all those items from Sitecore (this will include templates, fields, field types, settings).
You can also use the search in the content editor to search for "itembucket" or "item bucket" and find related items that way.
Another way is to search with SQL directly in the master and core database.
Once you have removed everything in Sitecore and configuration that is related to the buckets, rebuild the link database and run a database cleanup (from control panel) and you should be good to go.
It's a dirty job...
If anyone has a better way, I'd love to hear about it!
the problem you are having there is that the item buckets code was compiled against Lucene.Net 2.9 and Sitecore 7 has v3.0.3.
You could add an assembley binding in in the web.config configuration/runtime section that maps the old version to the new and then fix any issues you get with deprecated methods etc...
You will probably also want to remove the Item Buckets module before the upgrade as suggested as the new bucket templates & items may conflict with the shared source versions. You would at least need to remove the Item buckets config and dll's from the bin folders as these could also conflict.
I don't think there is a simple way of doing it yet or Sitecore would have given out an upgrade path already.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
The senior developer (and the only person experienced with Django in our company) has moved away and left us. Shortly after this (following his instructions) we pushed a site live onto a shared server (we have full control over the server) and updated the version of Django to the latest release for the new site to work.
Since then we have had issues with the other Django project on there which was built using an older version.
The main issue that I have is that we have a crontab that sends an email to the client outlining their orders. I have taken a screen grab of the error that I am getting but if I am honest I am struggling to make any sense of it. The names have been changed to protect the innocent (client).
http://i-am-a-fish.co.uk/help.png
I have uploaded a screen grab again i-am-a-fish.co.uk/help2.png
All suggestions are very welcomed!
Deprecation warning is not the reason, you can ignore it (unless you want to fix and use hashlib). The reason is multipart_subtype which your custom EmailAlternativesMessage class is not defining. Try to find declaration of EmailAlternativesMessage and add
class EmailAlternativesMessage(EmailMessage):
multipart_subtype = 'alternative'
...
Now that your immediate problem is fixed, the real solution here is to use virtualenv to isolate each project's dependencies (including Django itself) from the others, so deploying a project based on recent Django doesn't require an immediate upgrade of every other site on the server.
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.