Checked the system settings and my ACP is set to "YES" on "Do you wish to prune spider logs regularly (default every 30 days)?". Is this normal that this table is running so big or am I just visited extremely often by spiders?
I´m running a farely small forum (almost 600 members) and they are not extremely active (maybe 1-2 new posts each day). But my database is growing quite big (78MB at the moment).
I´ve checked with PhPMyAdmin and currently these two Tables are taking the most space (not sure why the "b" is small letters, still thinks it´s "bytes" and not "bits"):
I know the first has to do with IP.SEO:s spider-log but i can´t find any way to clean them in the ACP. Any suggestions how I can get these two tables down in size from the ACP (prefer not meddling with the DB directly if not needed) without messing up my board (i know the built up log-information will go but that´s ok).
Found the string " update gallery_ images set image_feature_flag=0;" which i ran successfully and then ran it again with the flag set to "1". If I check the database all gallery_images have the image_feature_flag set to 1 but it´s still only showing pictures from 1 album when checking my gallery frontpage :sad:
Ok, well thanks for the info guys. Guess I have to find another way around this (guides might be the way to go). Could anyone suggest a good online-compressor which is simple enough for a 3-year old to use (only need to downsize and compress, nothing fancy).
I see your points about making a guide to use a online tool to shrink the image. But I still feel this should be an integrated function since I think this must be a common issue for IPB galleries.
And I don´t understand why the original file needs to be kept on the server since GD actually makes a copy for all different sizes used by the gallery. The original file just seems to be wasted taking up space on the server for no apparent reason.
If i were to use ImageMagick instead of GD 2.0, would that change anything or is it the code in IPB that´s using this "copying-solution"?
Seems like there´s no real use for the "original" file? Any way of setting it to get rid of the original once the copy is done?
With the file-restriction I had earlier a lot of images where not uploaded because my members don´t know how to resize them manually on a photo-editor. But at this rate I´m gonna run out of disc-space since they upload some 20-50 images all being 2-10MB in size.
I used to have a limit set on user groups so that my member could not upload a single file bigger than 250kb. Many of my members do not know how to handle a photo-editor-program and since have problem uploading images since they just copy them from the camera (meaning the file-size is somewhere around 2-3MB per file) and thus got an error since the file-size was to big.
I noticed today that i could set the pixel-size via "Full Size Image Dimensions" in the gallery settings and also the compression and thus make the server reduce any image that was uploaded instead though GD 2.0. This works fine and when a user upload a 3MB image in something like 2000x3000 pixels the server handles this and when watching an image it is indeed reduced to my pixel-size and if i download it and save to my HDD it´s more like 200-300KB.
But when i look at the statistics for Gallery it´s still showing these images to take up a lot of space on the server, does GD only resize the image on-the-fly when it´s being called from the server and not on the actual file when it´s being uploaded?
One of my users made a new album and had some problems uploading the photos to it so it got left empty. Today i picked this up and contacted the user and walked him through the process so now there´s finally some images in the album.
The gallery-counter dosen´t seem to have picked this up however since it´s showing 0 on the counter for the album and the images are also not included in the counter for the total amount of images in the gallery. I have tried updating cache and theme but it´s not helping. Any ideas what i need to run in the ACP to get this right?