The
http://origami.net and
http://pugs.net directories are fully populated now with the thumbshots. I should have kept a before/after sites, but I didn't ... so see if you can tell which were which. Origami.net was about 60% populated by Thumbshots.org, but pugs.net was only about 30%. So 70% of the images on Pugs.net were generated by my script. 40% on Origami.net were.
There is a lot of manual intervention here, and after importing the thumbshots there was a lot of tweaking I had to do. We are working on a more automated way of getting your database into shape for imports, and I still have a lot of sites to test on, but we can use some more. If your directory is under 1000 links, preferably around 500 or less, and you have tried to use the
http://thumbshots.org site and either dynamic or static linking, and find a lot of holes, we can make a deal for you. The more sites I work with, the more "errors" I'm learning to work around. Status 302's are the worst. Most are "add a /". Some are really 404's, and only a few are redirects.
Right now the script I run keeps all the images in one directory, I'm actually using the ../admin/tmp directory to hold them. This is why I need smaller directories, not large ones. The next block of code will use a hashing algorithm to store the files, and the files will be moved out of the temp directory and into their regular home -- so it will be full upgradeable. It will also "save" the Last_Good image, and try to determine if a new image is actually a 404 type problem.
The way the system works, is the URL of the site is encoded as an MD5 hash. So, Link ID's and other "unique" site identifiers are not used. It's all URL based. The image is keyed to a URL, not a "link", so the image is not stored in your Links table, or database at all, but is prepped by the template parser, then actually called/loaded by an <IMG> tag in the browser.
This creates some problems which may not be immediately obvious.
http://sitename.com and
http://sitename.com/ are *NOT* the same MD5 hash, so it won't find the image.
Similarly, adding or leaving out a "www." will generate a "new" url/image. What's worse, is if the site adds a redirect.
For a small directory, you can go through all your links, and see which images didn't load, and jump to it to see why. Using two windows, one the links admin to Database->Table->Links->Modify to see what the URL in your database is, vs the URL that comes up when the link is clicked, you can "upgrade" many of the links in your database to the "new" URL. You'll be surprised how many have moved. I was. Adding a "/" will often cause the image to appear.
The good news is, this is working, and we can offer an affordable service for smaller sites looking to fill in images. It includes a scrub, and fix up, removal of links with a status code <=0 or >=400, and updating 302 links. If you do the scrubbing of your database, you save all the labor charges, which are the big deal.
We'll post instructions, helper scripts, and what you need to send us to fill in your directory. I'm going to move this discussion to
http://ultranerds.com/forum since it's starting to get into a non GT business realm here.
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.
