I have got this error of the maain page. How to fix it?
http://www.hippomocks.com/Talk:Main_Page
The revision #0 of the page named "Main Page" does not exist.
This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.
According to Mediawiki:
Database inconsistencies occur when, for example, primary keys stored in other fields no longer point to a row that exists. This can happen after a database import ends prematurely, for example. In that case, page.page_latest might point to a revision that hasn't been imported, and users trying to read the page might get an error message stating "The revision #0 of the page named '[page name]" does not exist. This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log."
The maintenance script findAnomalies.php can be used to find missing revisions. From CLI on your server, cd to the maintenance directory in your Mediawiki directory and run the script. e.g.:
cd /var/www/html/wiki/maintenance
php findAnomolies.php
And try some extra stuff
The error message you get sounds like in the page table, the entry of the according page points to a non-existing revision. This might be fixable by running the maintenance script attachLatest.php. This should make the page point to the newest revision again. This would be what I would try first.
If that does not work and you in fact want to delete the page, I would try running the maintenance script nukePage.php. This script allows you to permanently(!) delete a page from the database. Afterwards you can use the script purgeOldText.php to delete unused rows from the text table.
However, note that your database currently is in an inconsistent state; although the scripts I mentioned were partly written for situations of brokenness, there is no guarantee that they can solve this.
Related
I read packagecontrol.io's doc
regarding messages.json, but what I'm referring to is the file tab that sublime text typically displays upon a new package install. It appears as a continuous roll of installation notes throughout multiple installations. It appears that this is a feed of the individual messages.json files displayed when the packages are downloaded. Is there a way to open the unified file that displays messages from multiple packages? Or is there a more common way to access these package files?
What you are asking about are the install and release messages pointed to by those keys inside messages.json. For example, from one of my packages,
{
"install": "messages/install.txt",
"1.2.1": "messages/1.2.1.txt",
"1.3.0": "messages/1.3.0.txt",
"1.3.1": "messages/1.3.1.txt",
"1.4.2": "messages/1.4.2.txt",
"2.0.1": "messages/2.0.0.txt",
"2.1.1": "messages/2.1.0.txt",
"2.2.0": "messages/2.2.0.txt",
"2.2.1": "messages/2.2.1.txt"
}
Whenever someone installs the package for the first time, Package Control prints the contents of messages/install.txt to that new view you mentioned. It will also print the file corresponding to the current release, which is a "release" tagged on Github. If I were to go and release 2.3.0, for example, and not update messages.json, no update message would be printed telling users I'd pushed out a new version. In some cases this is desirable, in case I had to quickly push out a point release to fix some stupid mistake I made in a major (or minor) release, not that I've ever done that before :) But, in most cases, I want to keep users up to date on development, so I'll write a message for them in a new file, and add an appropriate key and value to messages.json.
Is there a way to open the unified file that displays messages from multiple packages? Or is there a more common way to access these package files?
The view that opens and shows you the messages from all the newly-installed and -upgraded packages is unique to you and your particular situation - there is no way to recover it once you close the tab. However, if you're interested in a particular package's message(s), just use PackageResourceViewer (in ST3) to open the package, view the messages.json file to see which is the most recent file you want to view, then find and read that file. In ST2 all packages are already unpacked in your Packages folder.
I had a bunch of unsaved scripts open. Today I restarted MySQL Workbench, there was an error message and now the scripts are gone. Is there a way to restore them somehow?
You can try to find your script in History Output. Check this answer: MySql workbench query history ( last executed query / queries ) i.e. create / alter table, select, insert update queries
If the save snapshot option is enable (this can be done by --> Edit>Preferences>SQL Editor>Save snapshot of open editors on close) then you can find the data in \%APPDATA%\MySQL\Workbench\log\sql_actions_unconnected.log. It is a log file, you can copy your code and paste it in a code editor which would put the code in the right format
This just happened to me and thankfully it turns out MySQL Workbench does actually autosave tab contents to disk. You can find them starting at your base configuration file path which is described here. The path to the scratch files is something like this:
{BASE_CONFIG_PATH}/sql_workspaces/{CONNECTION_NAME}.autosave/
Inside that folder is a bunch of .scratch files, looks like one per tab you had open for that connection. They're named with UUIDs, but just drop them all in a text editor and you should be able to find your lost tab contents pretty quickly.
If they're gone, they're gone, unfortunately. You should save them before you exit WorkBench (CTRL+S), since it has been very prone to errors like that, at least to me.
I'm exporting an old release 1.9.2 and importing to 3.0.2.
Each module has dozens of videos that I play via an URL/link, which points to my own .PHP program on the site (and that wraps a Camtasia video).
I found that in 3.0.2, the link opens on a separate page, unless I edit each link by going to "Appearance", then "Display" and setting it to "Embed".
So I would like to write a mySQL update script to automatically set this flag for all such links (I will add a where clause to my script name).
I checked database in PHP/MyAdmin, and didn't see any likely table names.
You should attempt to use the admin tools to update everything, go to your moodle installation's main URL.
Then go to the site administration. After /admin in the url, add /tool/replace and go there.
You can there enter what you want to find in the db, and replace it with another value. Just be carefull with this tool and make a backup before you begin.
chrome.fileSystem.isRestorable is a new part of the chrome.fileSystem API and it saif if a file can be restored with its entry or not. I've made many tests but something is wrong, when I tried to do :
chrome.storage.local.get(
["recentFileId1"],
function(recent) {
chrome.fileSystem.isRestorable(
recent["recentFileId1"],
function (isRestorable){
console.log(isRestorable);
});
});
It returns me true, even if the file has been deleted of my computer. recentFileId1 seems like a real id (many numbers and the path at the end, for example FD158F2A41037D17440C025C1CA5FE08:question.txt) and the file's restoration works if the file is still on my computer. When I tried to restore the file with an id of a deleted file it just returns nothing, no error.
So I want to know : did I use this feature wrong or something? It can work if I try to restore and see what is restored (if it returns nothing the file has been deleted), but I don't want to use a hack if the API is available.
Thanks.
This function is currently only available in the dev channel of Chrome, and should be released to stable in version 31.
What you're describing sounds like a bug, please file it at http://crbug.com. We should always return true or false. What the correct behavior in this case should be is not clear.
The intent of this function is to let an app know if it should provide UI to give the user access to previously opened files. If a file is restorable, it simply means the app still has permission to access the file.
We are reserving the right to limit when files are restorable. E.g. we might have an arbitrary upper limit to how many files can be restored, or the access might timeout after a few months, or we may give the user the option of not letting apps restore any files. isRestorable lets you know if access to a previously opened file is still available.
isRestorable is not intended to give information about how accessible the file still is. Local changes can impact this - e.g. the file might be deleted or the OS access permissions changed. It might still be there but be invisible to chrome and the app due to no read access to the containing folder.
Think about a recent documents menu. This could show files which were opened and since deleted. When the app restores a deleted app it would not work and would show an error to the user. At that point the user might go to their recycle bin or git checkout and replace the file.
Or the recent documents menu could just not show files which have been deleted.
Either way your app should not rely on isRestorable as an indication of whether a file entry can be regained and successfully used, you should handle restoreFile not restoring a file and giving an error, and handle access to the file having permission problems.
After using a particular interwiki link for a while on my wiki (Mediawiki 1.15.1), the other wiki changed its domain name, and I'd like to update my interwiki links. I changed the URL in the mw_interwiki table, but the links aren't updating.
I have tried adding "?action=purge" on the page with the links. I do not appear to have $wgInterwikiCache set in my LocalSettings file, and the mw_transcache table has no rows in it.
Is there something else I need to do to trigger an interwiki URL update?
EDIT Time solved this problem; after a few hours the links updated, so it's probably a caching issue. Not sure what process would be best to force a cache break if ?action=purge doesn't do it, though.
Using version 1.4.1 of Extension:Interwiki (on MediaWiki 1.20.2), I had the same problem. Even after deleting the interwiki entry, page previews continued to use the previously-stored value.
Upgrading to Interwiki 2.2 20120425 caused my next interwiki edit attempt to fail, but I was able to delete the entry and recreate it; after that, the links finally updated.
Use Extension:Interwiki to do the change. It will update the links instantly.