I'm just playing with Wise For Windows Installer for the first time, and I'm trying to modify things so that the installation folder (INSTALLDIR) (currently c:\abc) gets sent to c:\program files\abc as a default instead... I'm basically trying to change the suggested installation folder that is offered when the user runs the installation script.
Anyone got any ideas how I might do this? I've played around with it for a hour, but I think the time has come to cast a wider net...
Cheers,
Martin.
For anyone who has the same problem, it turns out that it can be amended on the Product Details page (the Default Directory setting...)
Martin
Related
I have no idea what is happening. I don't even know what information would be relevant, so please ask me anything you think could be related. The problem: I write a html script and css to modify it. I put the files on my webserver (Apache2 running on Ubuntu 22.04) and they work perfectly. I can modify the css script (e.g. changing font sizes, margins etc.) and the changes show up on the corresponding html. Yet, if I leave the laptop alone for an hour or so (not changing a thing), and I modify the css script it has zero effect on the corresponding html. It's as if no changes have been made. I can delete the files, write them over again and they work fine; leave it alone for a period of time and it no longer works. This holds true for all my html/css files. All help is greatly appreciated. Thanks.
I tried restarting Apache, restarting the laptop, rewriting the files, renaming the files, moving the files. No matter what I do, after a period I can no longer modify the html with css.
The first step would be to identify the source of the issue. This can be done by checking the Apache server error logs, as well as any other relevant logs from the Ubuntu OS. The error logs may help identify the root cause of the problem, such as a configuration issue or a software bug.
Once the source of the issue is identified, the next step is to attempt to troubleshoot the problem. This could include checking the web server's configuration, ensuring the correct permissions are set for the HTML and CSS files, and ensuring the server has the correct modules installed to support HTML and CSS.
Additionally, it may be helpful to check the browser's cache to ensure the HTML and CSS files are being served correctly, as a cached version of the page may be loading instead of the updated version.
Finally, it could be helpful to test the same setup with a different web server, such as Nginx, to determine if the issue is with the server or something else.
Ultimately, the devil in the details may be something as simple as a configuration issue or a software bug, or it may be something more complex such as an issue with the browser's cache. Identifying the root cause of the issue will be key to resolving the problem.
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.
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 am trying to import two 32-bit registry files into a Win 7 64-bit registry. While it says it was
successful, the changes don't show up. Not in the registry nor in the software I'm using. My goal is to add all my
Kontakt Sample Libraries into Kontakt's GUI all in one shot. It would save me months of work, instead of adding them
one at a time. This works perfectly in XP Pro SP3, on every computer I've built. But for the life of me I can't
figure out how to do it in Win 7 64-bit. I'll upload some pictures to illustrate the point, and hopefully one of
you Guru's will be able to guide me in the right direction? First of all here's a picture of Win 7 64-bit's
Registry. It shows the few libraries I've added by hand. A slow and tedious process.
enter link description here
Next is a picture of XP's Registry (how I would like my Win 7 Registry to look) To get these libraries all
added at once in XP all I did was import these two reg. files. Current User Native Instruments and Local Machine
Native Instruments. Then all my libraries were populated instantly. The actual libraries and their waves are on my
E:\ Drive. This is merely a way of pointing to them, so Kontakt can see them. I'll upload those reg. files so
someone can test adding them to their Registry.
enter link description here
Sorry there doesn't seem to be any way to add files to this post. So next is a picture of how Kontakt looks in XP Pro, (the way it should in Win 7.)
(Sorry, a third link or a third picture not permitted without 10 Rep points!!) OMG!!
Hopefully this will make sense to someone? Does anyone have any idea what I'm doing wrong? It sure would save me a ton of time, if you could direct me on how to do this correctly. Thanks in advance for your time.
Rob,
P.S. It won't allow me to post pictures or more than 2 links without 10 Rep points. Man, oh man!!
I would like to change the Packages directory location or add a new one (to be on network drive.)
I can't use the symlink.
I had a look on the plugins, but can't find.
I am on Windows Vista, Windows 8 (soon.)
Thank you for your help.
Christophe
If a moderator could please turn this post into a comment, because it is only a potential workaround to the issue (rather than a complete solution).
Using an OSX operating system, I am automatically backing-up (to Dropbox with a symlink) the entire SublimeText2 folder and subfolders within the application support directory. Inasmuch as Dropbox works on different platforms, perhaps this will give the original poster some ideas to have multiple computers using the same Packages data. I am successfully using this method to automatically synchronize all three (3) of my computers -- i.e., if anything changes on one computer in the Packages directory or subdirectories, then all computers are automatically synchronized.
Of course, back up your data on each computer before trying out this method.