I've just inherited a Magento site from a web development agency. I've migrated it across and it all seems to be working fine, aside from some images are missing.
I've worked out that it's because the previous developers have uploaded files into folders with case-sensitive names. So for example, inside the media/catalog/product/ folder, they have two folders name /s/ and /S/
Their system obviously allows these case-sensitive file names. Mine does not!
What has happened is that, as the files were copied across to my server, the system has combined /s/ and /S/ into one folder, and given it the uppercase name (/S/). The problem is then that Magento tried to reference some images at /s/ and of course it can't find them, as on my server that folder does not exist.
I have lots of folders where this has happened, amounting to thousands of product images.
Does anyone know how to get around this? Is it possible to change the server settings to accept case-sensitive folder and file names? Or do I need to go through the database and do some sort of REGEX to replace all lowercase folder names with uppercase folder names?
In the latter case, does anyone know how to do that and which database tables are involved?
Thanks in advance for your help!
First correction to a misconception --> I've worked out that it's because the previous developers have uploaded files into folders with case-sensitive names.
They didn't do this, this is how Magento stores files that it has processed and moved to its media directories.
Magento expects to be run on an operating system that fully understands and uses case on file names. *nix and Mac OS-X use this natively, Windows understands it in a sort of Compatibility Mode. Your major issue comes about with what you use as a transfer method between the different OS's that corrupts it.
The easiest way is to ask them for a zipped tarball and then use Windows 7-zip to dearchive it on your Windows system. There's too much work involved to mess around with correcting this after the fact, use a transfer method from their server to yours that preserves case.
Related
I recently made my own personal MediaWiki and I would like it to be available on different computers. I set it up with XAMPP, so currently, what I did was make two repositories:
one for xampp\htdocs\(my-wiki)
one for xampp\mysql\data\(my-sql-folder)
Then I cloned those repositories to the same folders on another computer. However, when I go to localhost(my-wiki) on that computer, I get the error "Sorry! This site is experiencing technical difficulties. (Cannot access the database)."
Whenever I make changes to the Wiki, xampp\htdocs(my-wiki) does not change at all, while xampp\mysql\data(my-sql-folder) frequently shows edits. What am I doing wrong?
Edit: After looking at the internal error data, it appears that none of the tables in the wiki exist anymore (Table xxx doesn't exist in engine). I'm unsure of why this would be!
There are two things that change when you use a wiki: the uploads directory and the database, so for some some sort of decentralized wiki you need to replicate those. Uploads are simple (you could use git, or some shared central storage like NFS, or some decentralized file store - Wikipedia for example uses Swift). As for the database, there are a few experimental tools to use git as a storage engine (e.g. git-mediawiki), but nothing I would rely on. If your computers run all the time, you can use database replication, but that's not a beginner-level setup. In practice you'll probably be best off just using database dumps. Or buy a server on the internet (a decent VPS is pretty cheap these days) and use that as the wiki's DB backend so you can reach it from all your machines. (Or I guess you can just put your whole wiki on the internet at that point.)
Figured it out. I was missing the files ib_logfile0, ib_logfile1, and ibdata1 from the xampp/mysql/data folder. This, however, makes my Git setup even more annoying. If anybody has any suggestions for a better way to setup my Wiki and make it available across different computers, it'd be much appreciated! Thanks
We have a lot of products that are saving their "states" on the registry.
What is the best practice on saving program states? What are the advantages/disadvantages of saving program states as a registry entry or saving program states to a flat file such as XML?
Thanks!
The obvious awswer would be that storing those states in a normal file, makes it easier for users to backup/restore the state manually.
Also consider that the registry has some keys that are special for each user in the system.
I think registry is the best option to store user-specific information that can be discarded and recovered easily (eg, the last username used to login). Other data should be in a settings file that can be backed-up.
For years programmers had their app settings stored in config files. Then the times changed, and for years they used the registry instead - many of them used it badly, and it caused issues when Vista and its UAC came on the scene.
Nowadays, especially in the .Net world, Windows developers are moving back to storing stuff in config files again. Personally i think that is the best way, if you need to move your app to another machine, or reinstall your OS, all you have to make sure you do is save your config file to retain your settings.
There are things that you may still want to store in the registry though, such as (encrypted) licencing info. For everything else, config files are good. Do pay attention to UAC and file virtualisation though, so that you don't run in to trouble further down the track.
Personally I'd go for the flat file.
(I am assuming that "registry" means windows registry?)
A flat file allows you (or even the user) to inspect and eventually even modify manually the values.
Depending on your situation this could be helpful for debugging, repairing mis-saved data etc.
Unless you thing you want to have the data to be "opaque" and therefore "hard to find/manipulate", the registry offers little in terms of benefits. Maybe it's faster, but if you have lots of state to save you better use an embedded DB instead of a flat file.
I used to follow Redmond doctrines. My programs used .INI files. Then I dutifully switched to the registry - and users started complaining. So, I bucked the trend and switched back to .INI files.
Some want to edit them (good/bad?). Some want to back them up, or transfer to a new machine. Some don't want to lose them if they reinstall windows.
AS a user, I have multiple partitions. Windows/programs/data/swap (and a few others). No programs go onto c:\program files, they all go into the programs partition. No data which I can control goes into c:\user data, it all goes into the data partition (use tweakui power toy, or regedit to change the defaults (but not all programs are well behaved and read the registry for those paths - some just hard code them)).
Bottom line - when Windows gets its panties in a fankle, I do a total re-insatll (approx every three months), and I format the C: drive.
By formatting the windows partition, I get a clean install. My data and programs are safe, though I may need to reinstall a few programs, which is why I go with portable versions where at all possible.
Imo, the registry is the biggest evil ever perpetrated on Windows - a single point of failure.
My advice? Locally stored config files. INI if the user is allowed to edit, serialized or binary format if not.
Or, you could offer a choice ...
Personally I go for a flat file, whether it's an INI file or XML file makes no difference to me. However in my line of work, we've had customers prefer the registry instead due to issues relating to deployment. It depends on who your client base is, and what the person keeping your product working prefers.
I always use regular files because its much easier to develop =)
Simple io vs I don't remember how read/write registry
Simple file copy/paste vs export/import keys for backup/developpement multiple versions of config for testing
Note that all of these advantages also translate into deployment strategies and generic client usage of the configurations
Depends how heavy deployment is. Most of my applications are XCopy-Deployable, that is they don't need an installer and can just be copied/unzipped. So I use .ini Files (using my own INI File Parser as .net has no built in one)
However, if your application needs to be centrally manageable (for example, using Windows Group Policies) or if you have a "heavy" installer anyway, the registry is the prime choice. This is because Applications that are installed normally to to C:\Program Files, and normal users do not have write access to this directory. Sure, there are Alternatives (%APPDATA% or Isolated Storage which has to be used when the Application is a Silverlight app), but you can as well "go with the flow".
Of course, if your application is supposed to run on Mono, you can rule out the Registry anyway and should go Flat Files.
Sorry I know this is not really a programming question.
But when for example on the MySQL website you are given the option to download a .zip or .msi file. Is the result exactly the same application, or do the two work slightly different. I.e. the .zip option being more self contained, with everything under the MySQL folder and nothing in the registry etc.
This will help a lot towards my problem and future problems.
if I plan to have single MySQL installation on single box - I use .msi
With multiple installations on single box .zip packges are easier to handle.
If you follow the links from the download page you can find an answer to this on the MySQL website.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.
I'm building an install using VS 2003. The install has an Excel workbook and two Access databases. I need to force the Access files to load regardless of the create/mod date of the existing databases on the user's computer. I currently use ORCA to force in a Version number on the two files, but would like to find a simpler, more elegant solution (hand editing a .msi file is not something I see as "best practice".
Is there a way to add a version number to the databases using Access that would then be used in the install?
Is there a better way for me to do this?
#LanceSc
I don't think MsiFileHash table will help here. See this excellent post by Aaron Stebner. Most likely last modified date of Access database on client computer will be different from its creation date. Windows Installer will correctly assume that the file has changed since installation and will not replace it.
The right way to solve this (as question author pointed out) is to set Version field in File table.
Unfortunately setup projects in Visual Studio are very limited. You can create simple VBS script that would modify records in File table (using SQL) but I suggest looking at alternative setup authoring tools instead, such as WiX, InstallShield or Wise. WiX in my opinion is the best.
Since it sounds like you don't have properly versioned resources, have you tried changing the REINSTALLMODE property?
IIRC, in the default value of 'omus', it's the 'o' flag that's only allowing you to install if you have an older version. You may try changing this from 'o' to 'e'. Be warned that this will overwrite missing, older AND equally versioned files.
Manually adding in versions was the wrong way to start, but this should ensure that you don't have to manually bump up the version numbers to get them to install.
Look into Build Events for your project. It may be possible to rev the versions of the files during a build event. [Just don't quote me on that]. I am not sure if you can or not, but that would be the place I would start investigating first.
You should populate the MsiFileHash table for these files. Look at WiFilVer.vbs thtat is part of the Microsoft Platform SDK to see how to do this.
My other suggestion would be to look at WiX instead of Visual Studio 2003 for doing installs. Visual Studio 2003 has very limited MSI support and you can end up spending a lot of time fighting it, rather than getting useful work don.