I have installed a fresh install of XWiki on a Windows platform.
The XWiki instance was installed using hsql for data storage.
The XWiki instance is hosted on Apache Tomcat.
Some of my users entered an apostrophe into the title of a page as well as the page content.
I received the following error:
http://jira.xwiki.org/jira/browse/XE-767
What is my next step to fix my broken XWiki instance?
Is there a way to upgrade a XWiki instance to a version that works? How do I save my existing content?
From reviewing the developers comments, it appears that issue has been corrected.
I, however, do not have enough background in Java or XWiki to know how I can move forward.
Thank you in advance for your help.
Indeed, the best solution is to upgrade to a newer version. Don't worry, upgrades are not that difficult.
http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation
There are two parts in an upgrade: the platform, meaning all the files on the filesystem, and the wiki content, since quite often things change in the default wiki documents. Your specific bug can be fixed by upgrading the platform part, so if you're not too confident about upgrading the wiki content, you can just leave the old content in place.
In order not to lose your current database, be sure to leave the old "database" folder in place, and just replace the "webapps\xwiki" part.
From the error report the versions that fix the issue are
2.7 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise27
2.6.1 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise261
You can upgrade to one of them or to any following version, like XE
3.0 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30
All versions can be downloaded from http://forge.ow2.org/project/showfiles.php?group_id=170
In a project that has such a rapid development cycle is very good to upgrade often in order to benefit from the latest features and bug fixes.
Related
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
Can someone please enlighten me. I'm trying to upgrade my Glassfish 2.1.1 to Glassfish 4.1. I've decided to do a side by side install as indicated here: https://docs.oracle.com/cd/E26576_01/doc.312/e24942/upgrading-legacy-installation.htm#GSUPG00039
Question are:
(1) What is "as-install"? There's no such directory as-install\bin in my extracted glassfish4 so I assumed it is the installation directory? Is it glassfish4\bin or glassfish4\glassfish\bin?
(2) I can't see the asupgrade.bat file in my glassfish 4.1 so I'm not able to proceed with the steps on the above link. I'm not sure if the version is related since the document specifically says "upgrade to GlassFish Server 3.1". I can see a pkg directory, and there's also an updatetool.bat. I can't run the upgrade tool though since I'm in a closed environment (no internet).
(3) Is it okay to just delete the Sun folder (for Sun Glassfish Enterprise Server v2.1.1) and replace it with the glassfish4 folder (for Glassfish4.1)? Then I will just run my updated installer that supports the new server. Fresh install works, however we also want to try upgrade.
(4) Assuming #3 is not possible, are there any other way?
Sorry to ask this here since I'm not familiar to any Oracle/Sun community. Google search' top results doesn't specifically answer these questions.
UPDATE: Apparently, I found a similar unanswered thread here: Where is the Glassfish 4 upgrade tool . Same issue, upgradetool is no where to be found. Also, tried to connecting to internet and I still can't update it via updatetool.bat.
UPDATE2: Apparently, updatetool.bat doesn't work for Glassfish4.1. I tried running it/installing it so that the upgradetool might be visible but it seems it can't download the application packages.
Apple's iOS 8 breaks certain tap functionality in versions of dojo prior to 1.9.4 (see Xpages mobile controls not working in iOS8
The current version of Dojo in Domino 9.0.1 FP2 is 1.9.2 but that does not fix the issue. You have to use at least 1.9.4.
I have downloaded 1.9.4 and placed it in the correct folder on our test server. But I cannot get things to work. I changed the folder name of dojo 1.9.4 to 1.4.0 as I only want to use this version for 2 dbs that are having the problem.
Question 1:
What line do I put in the xsp.properties file:
xsp.client.script.dojo.version = 1.4.0
xsp.client.script.dojo.path = / domjs / dojo-1.4.0
Question 2:
There are so many things to download when I go to the dojo download page. I downloaded the zip file and used that.
When I run code to test what version of dojo I have I get 1.9.4. But when I try to load my page, I get an error.
dojo._loaders: TypeError: dojo._loaders is undefined
Any help would be GREATLY appreciated.
You probably have the right dojo zip, this one: http://download.dojotoolkit.org/release-1.9.4/dojo-release-1.9.4.zip. As you say, unzip that to the dojo-1.9.4 folder in <server-install>\data\domino\js\, or name the folder 1.4.0 if you want to specify it for only a few apps.
You will indeed need to copy the IBM folder from the <server-install>\osgi\shared\eclipse\plugins\com.ibm.xsp.dojo_9.0.1.<date-stamp>\xsp.dojo.jar into your new 1.9.4 (or 1.4.0) dojo folder. Little chance of anything working without it. Copying the ibm folder from the 1.5.2 folder is a bad idea as that is old code, and you'd certainly have issues with it working with dojo 1.9.4. In Fix Pack 2, the ibm folder from the plugin was tested/designed to work with dojo 1.9.2 (the version in that jar), so it should play fairly nice with 1.9.4.
In your XPages app, in the xsp.properties, you should only need the line:
xsp.client.script.dojo.version = 1.9.4
Rebuild your app, restart the server etc, and you should be good to go.
DISCLAIMER: This is a work-around, not a supported solution by IBM. There may be unexpected issues using this approach. It's used at your own risk.
You commented already on that topic here so I think you tried this one? http://hasselba.ch/blog/?p=323
This is the SO thread: XPages mobile controls not working with iOS 8
Just getting ready to upgrade from 5.1 to 6.3. We have never performed an upgrade before.
About the upgrade path: When installing the updates, do I need to install the hotfixes, or just the major releases? (My gut says only major releases).
I found the documentation here:
http://www.sitefinity.com/documentation/documentationarticles/upgrading-you-sitefinity-5.1-project-to-the-latest-version
Is this documentation enough to make a smooth upgrade?
Yeah, just follow the documentation in the link you posted.
My process is to take full backups of the site files and database then perform the upgrade locally. Do the first step in the upgrade path then run through the site to test, back end and front end, then run the next step in the upgrade, and so on. I suppose if you want to be extra careful you could take additional backups between each upgrade step but that's probably overkill.
When making the web.config changes, there is an option to have Project Manager merge them for you but I end up just using Beyond Compare to compare the _EmptyProject folder in the extracted Project Manger files to my local files and do the web.config changes through a file compare. It cuts down on the differences in files from upgrade to upgrade and shows you whats been changed. The _EmptyProject folder is essentially the vanilla Sitefinty site files for that version.
Once the site is fully upgraded locally, I just publish the site in Visual Studio, copy the files over to the live site and overwrite the live database with a backup of my locally upgraded database.
Hope that helps.
I have upgraded Sitefinity 5.1 to 6.0, on a website which is in production (which included going through a couple of steps for the versions between).
I just followed the guidelines, and it went fine.
Now there are a couple of things you need to be aware of :
Source control
If your Sitefinity solution is on "Source Control", you should create a new duplicate of your solution, and disconnect this one(newly created) from "Source Control" before starting the upgrade. And of course you do the upgrade on the solution which is not in Source Control. Because you will probably have a lot of dll's to integrate, and if you have the project manager, your sitefinity project will run correctly, even though the new dll's aren't properly integrated in your solution and possibly "source control".
Unexpected behaviours of previously working elements
Secondly, I didn't test the frontend and backend during the different steps (Sitefinity versions within upgrade), but I tested everything once my solution had reached the last Sitefinity version. I thought I had checked everything, but it wasn't the case, and some of my custom Widgets didn't work properly on the latest version of Sitefinity. Next time I'll go more in detail on all custom parts, since from a working version of Sitefinity, you can end up with a newer version that breaks some behaviours. If you notice this, you might better wait a bit more for a fix, or the next release which might fix the problems.
Outside access to website during upgrade.
Furthermore, once you need to do the upgrade on the production database/website, the website shouldn't be accessed by people, since the upgrade of database might take some time.
Time needed for upgrading everything
One more thing I would like to add, it takes time to perform upgrade of several versions.
The first time I upgraded (I needed to go through 2 versions), and having to upgrade locally, to a development database, deploy the website on developement environment, then make it again on test. I took about 4 hours before everything was fully working. Make sure you have enough time, because it can be more tricky if you need to stop everything then come back to it.
So, in college I had a Debian server which used to host a wiki, with mediawiki version 1.9. This server stopped working, and all I have now is its HD. I want to transfer this wiki to a new server, which also runs Debian, but I can't do that with Debian's current stable version of mediawiki, 1.15, because it is not possible to transfer a wiki to another version of mediawii.
So, my idea is to install mediawiki 1.9 on the new server, and then move the wiki. But I am having problems with installing it.
When I go to http://my_hostname/config/index.php, to configure the new wiki, so that I can transfer the other one, I get the following message, and nothing happens:
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.3.3-7+squeeze8 installed"
I really don't have a clue on what is wrong. ANY help would be greatly appreciated!
Like you commented yourself, it would certainly be worth a try to using your existing configuration. The configuration is typically some site preferences and database configuration, so make sure dat your database is setup in the same way as before.
Regarding your configuration problems, maybe php filters away the errors. You can check this by searching for error_reporting in your php.ini.
Just follow the instructions at http://www.mediawiki.org/wiki/Manual:Upgrading. Probably no point in trying to install at MediaWiki 1.9.
You may want to do a clean install of MediaWiki 1.18.1 first just to make sure your system is ready, all dependencies met, etc.