Would it be possible to upgrade from MediaWiki from 1.15 to the latest stable version without losing data? I believe I will have a problem with database tables and extensions.
Thank you in advance
From personal experience I would recommend to take it easy and upgrade one major version at a time, especially when you do not have much experience with the process. This bite size approach will take longer but in return you will:
have to deal with fewer issues every time something is not right,
gradually update the LocalSettings.php as you go along every time moving it from the current to new release,
familiarise yourself with the Release Notes for each version - they contain notes on the configuration and breaking changes among other things, and finally
get comfortable with the process.
This approach helped me when I was upgrading from 1.27.3 to 1.31.8 first time in years. I came across problems at least twice and could not find relevant information on how to deal with them. The most annoying was no feedback from the update.php script or blank page when trying the new installation.
Below I include notes from my experience with updating MediaWiki in case that's of any help to anyone facing a big upgrade. These are just main points, so read the official Upgrading page too.
Installation
Don't extract a MediaWiki release archive into the existing wiki installation directory. Move the old instance to some backup directory and start afresh. Also make a back-up of the database.
Create a copy of LocalSettings.php from the original installation and comment out all custom extensions and skins as they will no longer be present.
Now as you bump the versions up:
Copy LocalSettings.php from the previous instance to the directory created while extracting a release archive. There does not seem to be a way to generate a fresh default LocalSettings.php during an upgrade, which would prevent some of the problems.
Run update script in the maintenance directory. There should be some output:
$ php update.php
MediaWiki 1.31.8 Updater
...
If there is no output at all that means there is likely a problem somewhere in the LocalSettings.php configuration. See the Debugging section below.
You should be able to access the wiki now.
Get a release archive of the next major version, read the Release Notes and repeat the steps.
Once you reached the target version you can gradually copy over all the custom changes from the old wiki (extensions, modifications, images, skins etc.) remembering to enable them in LocalSettings.php.
Keeping MediaWiki under version control makes it much easier to keep track of any customisations. Just make sure you keep the repository inaccessible to the world.
Debugging
In order to debug enable the following settings in LocalSettings.php:
$wgShowExceptionDetails = true;
$wgShowDBErrorBacktrace = true;
$wgShowSQLErrors = true;
Now go to the installation page https://.../mw-config/ (adjust the URL to match your set-up) and you should see some errors that might indicate what is wrong. For example, some skins or extensions from the older version may not supported any longer and you have to disable them in LocalSettings.php.
Once the configuration has been updated try again until you get to the web installer.
Once you managed to get to the web installer page stop there and try again with update.php script. It should work now. Close the web installer, there won't be any need to run it now.
Once update.php has finished you should be able to access the wiki. Disable the debug settings in LocalSettings.php.
In theory, yes - the update mechanism is a big array of database migration scripts, which gets expanded when you upgrade the code, so the number of versions doesn't really matter. In practice, that's a long way to go, so it's very unlikely anyone else has tested that specific upgrade path. Make sure to backup first.
One notable exception is HitCounter data, which does get dropped, as that functionality was removed from MediaWiki. See that page for workarounds.
Related
I've tried gradlew html:clean and then gradlew html:dist
however, it never uses the newest code. It will continue to grab the code from somewhere else and compile older versions of it. I got it to use the newest code once but I am not sure what I did to get it to do that. I'm not sure what files to post here to help.
For development, there are two ways possible:
If you don't need to debug and did not already compile: Use html:clean and html:superdev and make sure to delete the browser cache => You will get a fresh version of your game
If you need to debug or the game is already running: Use html:superdev if you did not already, head to localhost:8080/html, click the button to enter superdev mode (at the upper left corner) and hit recompile => You will get a fresh version of your game ready for debugging
For releasing an update of your game:
You need to enforce that all users get a fresh copy of your game. You cannot rely on all users deleting their browser cache, therefore you need to use other tricks for that (changing the directory of the game for every build, using HTTP headers...). I recommend you to use game hosting sites like GameJolt ot itch.io. They do this magic for you, and are trusted sites by players.
I found out the answer was to Shift-F5 to hard refresh the page. Chrome was caching the old info.
I am not sure if this is desired behaviour, but PhpStorm (8.0.3) proceeds to index all files and directories each time I open the IDE. The indexing takes too long - half hour and more. During that time I'm not able to access many configuration options or use "Go to definition" option.
It is very irritating. Shouldn't PhpStorm somehow cache the indices so that it does not go through the whole process over and over again?
It seems that the problem grew over time and at this time it totally paralizes my ability to work on projects.
Is there a solution to it that you know of?
is this problem still current? It's more than year since question, so it could be fixed already.
There is no reliable way to say why it's happenings without seeing the logs.
You may try this:
Close IDE (or this project at least)
Backup and delete .idea subfolder (this project settings)
Launch IDE and using "Open" point to the project root -- IDE will create new project from those files
Reconfigure your project as needed
Restart IDE / close-reopen project (do what you did in the past where it lead to project re-indexing)
It's better now?
If yes, and you have not re-configured ALL aspects of the project yet -- then you may re-use some of the files from previously
made backup (while IDE/project is closed, of course)
Try right-clicking file -> invalidate caches and restart. It worked for me!
File ==> Manage IDE Settings ==> Restore Default Settings
And now it loads rapidly
I had the same problem after searching a while I understood that .gitignore plugin caused it.
After disabling mentioned plugin ide backed to work correctly again.
I've been playing with IBM Bluemix (liking it a lot so far) and we are considering to use it for production. What I'm not totally clear on is what happens when runtime environments or services get updated. I assume this happens quite frequently.
Will the new version be always backward compatible? If so, is this guaranteed somewhere in the terms of service?
What I am trying to avoid is to put production code on the platform and then having to update it constantly (or having it break) due to runtime or service updates.
Does anyone have any experience? Have past updates always been backward compatible?
Mark
While I don't believe there is a guarantee that the buildpacks will always be backwards compatible, you will always be able to select the previous buildpack version.
Try running a 'cf buildpacks' command and have a look at the buildpack names and version info encoded therein and think you'll see what I mean.
When buildpacks are updated they won't be used for your application until you restage it, so you have some control over when to pick up the updates as well. This gives you a chance to test it on non-production versions of the app.
I'm working on modern Windows 8 app and wanted to figure out if Windows.Storage.ApplicationData.current.localSettings (msdn doc is here) get cleaned up when the app gets updated by the store.
Those settings are preserved across app updates, as are the roamingSettings and the contents of localFolder, roamingFolder, and tempFolder. In other words, performing an app update does not affect any of the appdata state, which makes perfect sense when you consider that many updates are minor bug fixes and should not in the least way require resetting or migrating existing state.
Do note that uninstalling an app and then reinstalling it will clean out localSettings, localFolder, and tempFolder. roamingSettings and roamingFolder will be restored provided that the user has had the app installed on another device within some reasonable period of time (unspecified, but something like 30 days).
It's also good to know that app state has its own versioning scheme through ApplicationData.setVersionAsync, and that an app update can choose, if it wants to migrate appdata from one version to another. Examples can be found in the Application Data sample.
No, your local settings will persist between app updates.
After publishing a new version of our extension to production, we sometimes see a weird behavior:
The extension on the browsers seems to be only partly updated (after given some time).
Our internal version number (part of our code) shows in such cases a previous version number, although some features and resources from the newer version already exist.
We have seen this occasionally in all browsers and on different operating systems.
Any idea why is that and what can be done?
Note: our extention.js and popup.html files are about 380kb (I don't know if that makes any difference).
Whilst I don't know the specifics of your scenario, in general, updates are automatically checked for and pulled if required by the extension several times a day. If there is anything that interrupts the process such as connectivity problems, then a partial update may occur though there are mechanisms in place to try and protect against this. Also, note that resources update if there are changes to one of the core files (extension.js or background.js).
[Disclosure: I am a Crossrider employee]