I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.
Related
I found all of these answers to a question I had:
Store pictures as files or in the database for a web app?
Storing images in SQL Server?
To Do or Not to Do: Store Images in a Database
And the last one links to even more versions of the same question. They typically have the same answer, suggesting to use a file system, then store the address in a data base. When they say "file system", do they mean store it in the folders that you use to make the website?
The way I've been learning to make websites, there's the "views" folder that has all the layouts, then there's the "public" folder that stores your css and js files. Then I have a line of code in the app so I don't have to type public all the time when I'm linking to my css files or js files. So would I store the images in there? With it's own folder and maybe a folder for each user? What happens when there's a lot of users and a lot of pictures?
Or should the pictures go somewhere else entirely?
I've done my best to find the answer on my own, but "file system" is such a generic term, I can't find the specific answer.
Yes, filesystem means to put them as files alongside the files that your website consists of.
Generally, there are a couple good practices to follow when doing so:
Put them in some folder that's dedicated to user data, not to the same folder you put your website's core files
Generate artificial file names (UUIDs or database-generated IDs) for them instead of using the original file names to avoid name collisions
If you expect a lot of files, on some filesystems it may be a good practice to create a level of subdirectories to limit number of items in each directory
It might be a good idea (depending on your use case) to forbid direct access to this folder with user data through plain HTML
Instead read the files and output them through your script
This is required if the files are not all public (if any authorization is needed to see them)
This might be more of a user question rather than a developer question. but developers should be able to offer insights.
For the person creating and editing content, what's the best practice for where to store images associates with pages? (I'm referring to the Plone folder, not the file system directory).
Should it be stored inside the same folder as the content item itself? Or a subfolder within the working directory? Or a special directory writeable by all for storing images?
If you do some sort of shared image upload Plone folder, what would the permissions on that Plone folder be? Once again, I'm referring of course to the Plone folder, not the file system directory.
I see that in the site admin TinyMCE options you can configure some default paths for image uploads. How would you do it so that the user won't be overwhelmed by all the images in a common images folder? (in other words, he can see and edit only his own image uploads).
This is truly a serious weakness in Plone, in the sense there is no "Best or More Oftenly Recommended Way". As #keul highlighted, Plone is flexible enough to support almost every imaginable usecase, nevertheless I can't see much of a consensus - neither a set of common steps - to fulfill the common usecase you described, in a hierarchical-and-permissioned paradigm.
That said I recommend you to check and share opinions, feature requests and code on the second of these:
https://pypi.python.org/pypi/Products.ImageRepository
https://github.com/plone/plone.app.mediarepository
Both focus on easing the use of tags to manage the overwhelming of items you described. I believe this kind of problem would mostly arise when adding images inside TinyMCE sessions, say, adding a News item. However if you just need to update images for sections or the homepage I recommend you to take a look at collective.cover:
http://www.youtube.com/watch?v=h_rsSL1e4i4
btw I also recommend you to check these solutions for richer image handling:
https://pypi.python.org/pypi/plone.app.imagecropping
https://pypi.python.org/pypi/Products.ImageEditor
https://pypi.python.org/pypi/unweb.iptc/
I'm looking for a simple tool that would allow users to update and tag assets.
THen search/browse for assets and view the assets in the search results.
I have lots of files, i.e. logos, buttons, infographics, icons. I'd like to be able to share the with co-workers and have them be able to easily locate them without have to guess based on file names.
Right now I'm using apache with dir listing and htaccess. But this is less than ideal.
Are you talking about Version Controls? If so, Git can help.
CKeditor's installation instructions tell me to just unzip the whole distribution file on my webserver's production directory. But it is full of files I definitely don't want there, like source code, examples, and even server-side code in PHP. I got rid of most of these files but there is one I'm not sure about: contents.css.
I can see this file uses a lot of styles I definitely don't want to see in my site. My question is:
Is contents.css required by CKeditor, or used by default? Do I even need this file on my production site?
I suppose it depends on what you're using in CKeditor, or what you plan to use later. Personally, I'd suggest renaming the file (something like) contents.css.old and creating a new contents.css file, copy across all the styles that you think you'll need and then destruct-test your implementation of CKeditor, to assess whether you've got all the styles that you need.
Add to, or remove from, that file to get your finished version and then use that one. I'd strongly advise keeping the original version around though, for future development purposes.
To your specific questions, though:
Is contents.css required by CKeditor, or used by default?
I believe so.
Do I even need this file on my production site?
Not so far as I know, its absence will likely cause things to look a little less-pretty, though, until you apply your own styles.
As suggested, above, though, I'd rename the original and then create your own stylesheet with the same name, it's rather easier than going through all the various js files looking for, and changing as appropriate, references to contents.css.
I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?
Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.
For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.
I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.
I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.
Here's a little more explanation of Graham's suggestion:
Create an images directory
Create an images Group in Xcode
Right-click the group and Get Info
"Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:
Created the directory on disk where I wanted it.
Went to the file menu
Right clicked on the group I wanted to add to
Selected "Add Files to PROJECTNAME"
Added the files from the directory I created in (1)
Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.
In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.
Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).
You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.
But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.
My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.
It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.
Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.