Gallery - http://schnell.dreamhosters.com/wallpapers.php
The purpose of this gallery is simple - store a lot of wallpapers and sort them by resolution and/or aspect ratio for people to browse and download as they like. There's a few features I've wanted to work in, but I'm not quite sure how best to do them or how to do them at all. The presentation is in HTML 4, CSS, Javascript and jQuery + plugins. The work behind the scenes is done in PHP.
1 - Make the images downloadable without 'Save Image As...'. Right now I'm using a contrivance whereby clicking the Download link in the bottom-right of each image's box opens a new box with instructions telling the user to 'Right Click. Save Image As...'. I'd like to avoid this entirely if possible.
2 - Make the searching and sorting faster and more efficient. Right now all the images are stored in a folder on my webspace and I use a shell command and a lot of fancy filtering in PHP to get the images I want based on the filters (the page number I'm on and the aspect ratio or resolution I chose). I thought of maybe doing something with MySQL, but I haven't quite figured out yet how I'd do that and maintain the structure my page has.
3 - Make the images load faster. There's probably no easy coding solution to this, so this one is more of a 'I wish' than a 'I want to'.
4 - Improve the layout. This one is more subjective and 'artsy' I suppose, but any suggestions would be nice.
5 - An upload system. Give the ability to upload your own wallpapers and maybe include a short description or some tags. I have absolutely no idea how to handle this as I've never worked with uploading of files before. And this also leads to...
6 - A tagging system or some other type of user-made sorting system. Again, no experience here.
Any insight on any of these issues would be great, and feel free to throw in any suggestions of your own.
Send the files with the MIME type "application/octet-stream" to make a browser download rather than display them
It would definitely be better to store information about the images in a database rather than exploring the filesystem
The images really aren't loading slowly for me, so I can't really suggest anything here. If your site gets larger (much larger) you might want to look into CDNs
The layout is OK but it needs some design, it's incredibly plain at the moment. It would also be nice to see more information on the images - what they are of, where they're from, who made them, etc (don't forget: correct copyright attribution)
You probably want to read the PHP handbook section on handling file uploads. To handle description and tags, you'll definitely want a database of some sort.
Also not hard if you have a correctly formed database. If you've never designed a schema before you probably want to learn a little about normalisation and many-to-many relationships to do the tags.
Lastly you didn't ask for it, but it'd be nice if it were possible to have the same image in multiple resolutions (quite common on image sites - think Flickr, Deviantart, etc).
Related
I am building an avatar-generator for a PHP/MySQL site I am working on. It uses CSS to layer multiple .png files to create the background, body, facial expressions, etc. for a user's avatar. This I have covered.
I want to add a feature to my site that will allow the user to download their layered avatar "image" as one .jpg file. Is this even possible? I think I have seen this functionality before but can't recall the site where I saw this now.
Of course, I could come up with a series of pre-generated files that would cover all of the computations possible with my images, but with somewhere around 200 objects to choose from and a maximum of 10 layers of choices, the number of permutations possible is somewhere around 8.14702044e+22! Obviously, this is possible for me to do but I would be old and gray before completing the task!
Poking around the Internet has led me to believe there might be some way to "screen cap" - with what software and if it can capture a small section of the screen I don't know. Besides, would this bog down my site (which is currently running at top speed)?
I've searched through Stack Overflow for similar questions but didn't find anything that addresses my problem specifically. That said, I am not certain what to even search for (the precise terminology) as this concept of layering and saving as one image is foreign to me.
I found a solution to my own problem. It's not quite what I had in mind when planning this part of the project, but the end result will be close enough (with some other modifications).
I will implement html2canvas (http://html2canvas.hertzen.com) to take a screenshot of the user's avatar when they have pressed "Save". I will store the resultant image to my server and this will be their avatar. Their selected variable data will be stored in a database so that they can load up their avatar at a later date and make changes to it.
Since multiple requests can slow down the speed at which a site loads, I was thinking that in the case of a gallery, would one large image containing all the thumbnails be better than loading individual thumbnails?
The large image would then use PHP to "chop up" the thumbnails and place them in the relevant locations on the page.
My main concern is would this have a negative impact on SEO? Since Google would only see one large image file, instead of many smaller ones. Would a way around this be to set the src of all thumbnails to redirect to the script that handles the thumbnail generation, where the image file name refers to a particular set of coordinates for that image?
As a rule of the thumb; for buttons/icons/stufflikethat use image sprites (one large image combining all images, uses css to only show a part between specific coordinates), for 'real' content images, just use separate images.
This has several reasons; icons, buttons and so on are images that appear on sometimes every page of your site and often multiple times on the same page. So it is really useful to combine them, as ie. it is really inefficient to start a new http connection to download an icon of 1kb (or less), imagine what will happen if you use hundreds. Furthermore this type of images are not important at all for your seo rank, only for the look of your site (but google doesn't care if your site is ugly as hell or beautiful as a princess)
But on the other hand, 'content' images, such as thumbnails, photo's of your holiday or baseball tournament are often big enough to rule out the efficiency part. As you can see in the chrome developer tools or firebug the browser will start the download of all images simultaneously. So downloading one image is pretty much as fast as downloading a hundred. But if you combine a hundred images, the download will be slower, as you have to download a larger bit of data in one piece. In comparison; pushing 2 gallons of water trough one hose will take longer than pushing the same 2 gallons trough 10 hoses. (offcourse this metaphore has it's holes, but it illustrates my point).
But more importantly; google reads out the img tags and uses the filename (src), the title and (less importantly) the alt attributes to determine how your image should relate to your seo rank. Images do have a relevant effect on your seo rank! But google also knows if it is the same image showing, or a different one, so a sprite wouldn't help you here. A script, with parameters saying which part of the image has to be loaded wouldn't help you at all, I believe if you think it over you can figure out why ;)
So don't bother about merging the thumbnails and stuff like that. If you want to improve speed, move your attention to caching and speeding up transmission. Some really simple improvements can be implemented by using for example gzip compression (google .htaccess gzip for that), proper caching headers etc.
You got it right, it is always better to download one large image and get all the image from there, i guess you meant javascript with the chop out thing, because you have to do that on the client side. This in terms of performance is a very good idea and lot of sites do it. Another idea is to use smaller images and resize them in the client side.Just be careful with the resizing not affecting the resolution of the image.
Im not so sure about this being negative to SEO, and as far as i know google doesnt execute any javascript function, so that work around, i dont think it would work. But in all honesty im not so sure about this, in my last job we never considered images as a big impact in SEO.
I'm trying to create a mosaic type script in Javascript and PHP, which makes up a big image with many different images made from small square tiles. The idea was to "fake" the effect by having a background image and laying over the tiles on top of it, and making their opacity 50% or so. This works decently enough, but it definitely doesn't look as good as I want.
My question is, does anyone have any recommendations on alternatives to this method? I know there are definitely ways to do this in Flash, such as the Mario Lemieux mosaic:
http://www.mariomosaic.com/mosaic/
But I would like to avoid flash if possible.
edit: added live example
So I haven't touched the JS layer yet, this has all been server-side stuff. There's no pre-loader or anything really in terms of making it more usable, that will come soon. But here's what I've got so far:
http://www.mtimofiiv.net/mosaic_example/
The little tiny image tiles are created from images uploaded by a user, and they're run through a class I've built to generate them. I used GD2 to make them grayscale so they will absorb the color of the background image better, and I "pixelated" the background image in Photoshop.
If anyone wants to see any part of the code let me know and I'll add it to this post. Also when this project's done I intend to make it available on Github in its entirety for whoever wants to do the same.
Perhaps the fact that your demo HTML is 733KB might dissuade you from this particular approach. I think if you want to do something like this, you really ought to employ the canvas element, and work in some kind of "ajax" loading. That could actually be kind of interesting. However, if you are going to generate this much HTML...you might consider having a client-side script do it, if possible. Just some thoughts...
I'm using Drupal for the first time for a project at work. I'm finally getting my head wrapped around some of the core concepts, but when it comes to customizing output I'm unsure of how to proceed.
I have to build a fairly specialized image gallery. I've managed to cobble something workable together using Views2, but it's not quite where it needs to be. I'd like to write it from scratch, using SQL and actual PHP, rather than working through this web UI.
I figure I'll put this functionality in a new module. Is that right? Or is that an abomination to the Drupal world?
Edit:
Here's what I've got so far. I've created Image Gallery and Image content types with CCK. Images can be assigned to multiple galleries, via nodereference. I've got imagecache creating two sizes for each uploaded image - a thumbnail size and a gallery size.
Two gallery formats are required, but let's assume I'm going to have a carousel style for now, with some custom JQuery and CSS to match the rest of the site's look and feel. Clicking a thumb in the carousel-style navigator will load the full sized image above it.
Now, assuming such a thing does not exist, what is the recommended approach for creating it? Not how to code it, but where would this code live within the Drupal system?
It seems like views will do the job of creating the data you need - a list of all the images for the galleries, based on whatever criteria you need (taxonomy,author or whatever) and that the carousel part - adding the jquery and css could be done by using drupal's themeing system to change the output.
So as ar as 'where would the code live' I would say in your theme, rather than a module.
The views theming system is pretty comprehensive, if possibly a little overwhelming at first.
This looks like a good starting reference: http://www.group42.ca/theming_views_2_the_basics
You can do this. Views is great but will often only get you 90% of what you need out of the box.
You can do views theming, which can take you further, and you can write extentions to the views functionality (but that is not always easy).
There is nothing wrong with writing your own module in stead of views, in some cases it can increase performance. One tip if you are doing this is that you can see use the query that views creates in your custom module, this can save you having to work it out and write it yourself.
Yep, I'd put this in a module. I often wind up writing custom ones for specialised use cases.
Well since it is free software you are free to do (almost) whatever you want with it.
A good practice to decide if you should do it is:
Will the benefits that I will get from
a custom module divided by the time
I'm going to invest in it. Outweigh
the benefits / over time of a solution
that isn't ideal?
Or if you prefer to look it this way:
Custom Development Benefits Not 'ideal' solution benefits
--------------------------- > -----------------------------------
Development Time Time to install and adapt
Since normally the Time to install and adapt normally is smaller than the time to develop something from scratch, the common conclusion is to just use what is already there.
But by all means if you want to develop your own thing and have enough time, go ahead.
I'm a big fan of Yahoo's recommendations for speeding up websites. One of the recommendations is to combine images where possible to cut down on size and the number of requests. However, I've noticed that while it can be easy to use CSS sprites for layouts, other image uses aren't as easily combined. The primary example I'm thinking of is a blog or article list, where each blog or article also has an image associated with it. Those images can greatly affect load time and page size, especially if they aren't optimized. What I'm looking for, in concept or in practice, is a way to dynamically combine those images while running them through a loss-less compression using PHP.
A few added thoughts or concerns:
Combining the images and generating
a dynamic CSS stylesheet to position
the backgrounds of the images might
be one way to go about it, but I
also worry about accessibility and
semantics. As far as I understand,
CSS images should be used for layout
elements and the img tag (with the
alt attribute) should be used for
images that are meant to convey
information. I could set the image
as a background to a div element and
substitute a title attribute for the
alt attribute, but I'm unsure about
the accessibility and semantic
implications of doing so.
Might the GD library be a good
candidate for something like this?
Can you recommend other options?
I wouldn't go down this route if I were you. Sure, you may save a few bytes in protocol overhead by reducing the number of requests, but this would more-tha-likely end up being self-defeating.
Imagine this scenario:
A blog site, whose front page has 10 articles at a time. Each article has it's own image associated with it. To save a byte or two of transfer time, you programatically create a composite image of all 10 article images. You now have one of two problems.
You must update the composite image each time a new post is made, as the most recent 10 images will have a modified set of content.
You decide to create a new composite each request, on the fly.
Obviously, #1 is preferable here, and would not be difficult to implement. However, what if a user searches for all posts tagged with the word "SQL"? You are unlikely to have a composite image of the first 10 results already created for this simple query, let alone a more complex one. Also, what happens if you want to update or delete an image? Once again you'd have to trigger the background creation of the composite.
How about an RSS aggregator, like Google Reader? It wouldn't have the required logic to figure out which portion of a composite image it would need to display, and would probably display the full image. (I mention Google Reader because I very rarely visit blog sites directly, tending to trust to an RSS aggregation service like Reader)
If it were me, I'd leave the single images alone. With modern connection speeds, the tradeoff between additional bandwidth overhead and on-server processing time is unlikely to win you and great gains.
Having said that, if you decide to go down this route anyway, I'd say the GD library is an excellent place to start.
You'd almost certainly be better off reducing the filesize of the images in articles, than combine them. I'd agree that there might be accessibility issues with the method you suggest. Also, I suppose it depends on what you mean by "dynamic" - if you're thinking of combining those images and generating CSS for each page load, you might well find that that results in slower page load times for users with average connection speeds.
As to your second point, GD could certainly handle that. A better use of GD for reducing page load times might be reducing the image quality of your article images to reduce filesizes, at article creation time, not at page load.