• When I upload GIFs that have a transparent background, they will show up with black and definitly NON-transparent backgrounds when I go to use them. OK, this is definitely a word press issue, though I’ve found numerous complaints about this searching the forums in which wordpress was deemed innocent (That’s probably why its still a problem). So I’d like to submit this as a bug report.

    I have found a workaround which is a pain to do, but it also proves there is a problem with the normal wordpress upload, that apparently mangles GIF pallets and destroys the transparency. Here’s the work-around. Use normal FTP to upload your GIFs to a folder like IMGS in the root of your domain. Now when you want to add an image to a page, d o via the option to add from a URL. Then enter htpp://yourDomain/IMGS/yourFilename.GIF. THAT WORKS!!!

    And since uploading the SAME image the usual way does not work (the transparency is clobbered), this is fairly definite proof that the problem is in the wordpress handling and processing of graphics, which only happens using the FILE upload method.

Viewing 15 replies - 16 through 30 (of 31 total)
  • My simple point was, you had an issue with transparent gifs and how your host environment handles them. I would have been done with it and just converted to .png. Done.

    As for your host and what it can or cannot do with specific libraries, you need to ask them. And, as for plugins, some are designed to use the default handler for images on your server, some can be configured to use other libraries (which would need to be available on your server). Let’s also not forget what can be done with compression on servers to save disk space and how that itself can wreck some types of files.

    Thread Starter Peter_Pan

    (@peter_pan)

    OK,

    There’s not much else to say on this thread, but if nothing else, I’d suggest you keep it in the archives and don’t mark it ‘resolved” or delete it. It may benefit of other WP users, since the issue has been brought up in the past.

    To re-cap, the problem with GIF transparencies does NOT happen if you add graphics to a page using the option to add from a URL. Therefore, it makes sense to make a directory with your troublesome graphics in a directory (like IMGS) close to the root of your domain. Make sure to use simple FTP to put your files there. You can then browse to it with any browser to see all the available file names, view one of the (again from the browser), and then copy/paste the URL into the the URL box in the ADD media option for the page. Further, I believe you can make WP use a relative path to the graphic by modifying the copied URL from “https://yourdomain/IMGS/myfile.GIF” to simply “/IMGS/myfile.GIF”, and you’re done. Thus you can use your existing collection of GIFs without converting them all to PNGs, sacrificing animations, or trying to get something like ImageMagick to work. With this info, at least there is a choice.

    (That is happening for you…does not mean it happens for all).

    It also does not happen for me when I added them to a site. Can you respond to any noted issues with the images in the page I linked you to?

    I am not trying to beat a dead horse either, but I have tried to show you that it did not happen for me using your images…so is it all of us or a subset of us???

    Can you provide an animated gif with transparency and I will do the same on that page, upload with Media Gallery and display varying sizes?

    BTW, you can switch to the HTML tab and use the img button to add an image from your own imgs folder and then edit the url if you want to… (if you know which img you want, seeing them is rather helpful) of course, / is the same as yoursite.com…once a browser resolves a domain it does not have to look up every single instance of it. In days of old it may have been best to worry about such minor server issues, I have found them non existent today.

    And no one will mark resolved but you although it will be closed in a year.

    Thread Starter Peter_Pan

    (@peter_pan)

    1) The page you showed me looked fine. bear in mind the the images you now see on my page are also already fine, as they were added without going through the normal upload process. However, if you go to this image I uploaded through the normal process… https://elfintechnologies.com/wp-content/uploads/Stand_elf3x-268×342.gif, you’ll find an image that has been damaged by the process. I don’t know what you mean by a “subset of us”. But if it happens to more than 1 person, information on a workaround is worth a post I think. ??

    2) “HTML Tab”. Please explain? When I’m editing a page, I don’t see an “HTML” tab. I have an editor and an add media button, and the add-media button takes me to an “insert media” page, which is where I found the option to “insert from URL”, but there’s no HTML tab there either.

    Thread Starter Peter_Pan

    (@peter_pan)

    By the way, if anyone is having trouble getting the ImageMagic replacement for PHP GD to work, at least on my Hostmonster.com I found it didn’t like the default PHP.5.2, but finally worked correctly when I switched to 5.4. So at least for WP, my problems with GIFs are now solved. WP is my first experience with PHP so I don’t have to worry about breaking anything on my other domains with this company, but other’s milage may vary.

    wpismypuppet

    (@wordpressismypuppet)

    For what it’s worth… this is not a WordPress “bug”. This is a PHP bug. But it’s not even a bug. PHP has used the GD library for quite some time to handle image manipulation, but it’s not as good as ImageMagick. One of it’s flaws is keeping gif transparency on image resize! It also has problems with GIFs that are not 24 bit.

    What’s happening here… your current host does not support, or at least have enabled, ImageMagick natively. Because ImageMagick is not enabled, WordPress will fall back to GD to handle image “crunching”.

    When you use WordPress to upload images, WordPress sends that original image through a series of steps to make thumbnails. It uses PHP’s resize function to make thumbnails. PHP’s resize function is dependent upon which library is installed, and since you are using standard GD, you are having issues.

    The problem goes away when you FTP the image directly to the server because WordPress is not “crunching” the image through the PHP GD library anymore… so it’s not getting affected.

    Just wanted to clarify that this is NO FAULT of WordPress… it’s a problem with your host not using the latest version of PHP. Most hosting companies don’t even support 5.2 or lower anymore (actually since August 2011) and force you to upgrade.

    What @wpismypuppet said ??

    Thread Starter Peter_Pan

    (@peter_pan)

    wpismypuppet and WPRanger: I do understand this now, and thanks. But… its still odd that this pGD problem affects the original images though, which do not need to be re-sized by GD (more on that below). For me and for now, I’m wondering (and hoping) that if I ever use any other CMS systems that rely on the GD library in the future, I can coax them into using this Imagick too. Or better yet… maybe the PHP bug has been fixed. I was configured for 5.2, and now have set 5.4 for all my hosted domains. But it was set to 5.2 because I’ve had this hosting company for at least 1/2 dozen years, and having never used PHP before, never had cause or reason to change it.

    Now regarding wordpress not being at fault, technically you are right. I see that now. But I think that taking that tact misses a good opportunity to improve the WP experience. I’ve never used PHP before, and still build of simple and functional sites with just HTML, CSS, and Javascript. I imagine that a lot of people in my category come to the WP table with equally shallow knowledge of PHP. In fact, since WP is touted as a product for non web-tech savey folks to use, I’ll bet a huge number of WP users don’t have a clue what PHP is.

    Now keep that in mind when I tell you that as a windows programmer myself, I have been continually frustrated when a new OS version, or even a service pack or simple automatic update breaks my code. And even the best installer, that’s supposed to take every .DLL and resource a customer might need into account, still can easily miss things that can destroy a programs functionality. In such cases, I would always rush to say it wasn’t the fault of my program. But over time I’ve come to understand that from a user’s point of view, that’s the wrong answer, even if its technically correct, unless there really is nothing I can do about it.

    So to me, this is one of those cases. Granted its not WP’s fault. BUT… since there are billions of GIFs in the world, and since they still have a lot of benefits for their animation abilities, its worth doing something about it if you can do so with reasonably little effort. Here’s what I’d propose…

    1) The first time a user imports graphics into a library, detect if GIFs were involved and if so, give them a one time warning of a possible issue, and offer them a link to an information page with workarounds, explanations, and solutions. But also, if you consider step 2, you can also make them aware this will only affect the thumbnails…

    2) You can fix this without writing a new GD library or installing Imagick. All you need to do is modify WP so that when images are imported, only the thumbnail and icon size versions get passed through GD. For the full size initial graphic, there is no reason to do any graphic processing of any kind. If you need to rename the file (as WP seems to do) to append the graphic’s dimensions. That, of course, that can be done with a simple file system call. (If you can’t get the dimensions without a GD call, just make a copy of the graphic file in a TMP dir, let GD process the copy, and then use the processed file name to rename the original.) I’m sure PHP has file calls to allow renaming and copying without touching the file content The result would be that even if the thumbnail and icon sized instances are corrupt, no flaw in GD could EVER cause the problem I encountered. That would pretty much make it a NON issue to all users.

    Now again, everyone can argue that this problem is not specifically WPs fault, and you are all technically correct. But, if a change as simple as I’m suggesting can eliminate the problem (except for the thumbnails), then NOT making that change as part of a future version IS WPs fault. Its no different than when a new version of Windows breaks my code. If a user brings it to my attention, and I have a solution, sure I’ll explain that the fault was in the windows update, but I’ll also fix it if I can, rather than suggest the user jum through more hoops than necessary. Its just the right thing to do.

    Yes I understand that WP is free, and so all the coders must be contributing their time. But I think my suggestion is a pretty easy fix, and will definitely save others from this frustration. Remember that to a layman trying to use WP, understanding the PHP GD issue and getting Imagic to work will be beyond many of them. Here’s a fairly simply way to eliminate the hassle.

    wpismypuppet

    (@wordpressismypuppet)

    Look, I’m not trying to be argumentative or even insulting, but what you are asking for is a fix that does not exist with over 98% of all WordPress users. The reason it doesn’t exist is because all hosting companies offer a later version of PHP which fixes any and all issues you are talking about. The reason you experienced this problem is because your hosting company wasn’t proactive in getting everyone in their system up to snuff. If you want to point fingers, I guess that would be a good place to start.

    On a second note, asking to create a fix to a problem that only occurs in obsolete situations is like asking you, as a Windows programmer, to make sure your application accommodates a bug found only on Windows 3.0, released in 1990. It’s just not practical. The version of PHP you were using was outdated, so WordPress should not have to provide a fix to a bug for a software package no longer supported by the very people who created it!

    Only a rare few will experience your situation and there is a simple fix. Upgrade PHP, or find a new host who does that for you on a regular basis.

    The other reason it’s a rare problem is because the GIF file, though magnificent in its own time, has also become obsolete. If a user wants a simple transparent static image, they create a PNG which has far superior transparency/color properties. If the user wants an animated image for whatever reason, they can use a scalable vector graphic (SVG), JavaScript, HTML5 canvas, or CSS3 animations (note how I left out Flash… we won’t even go there). SVGs are superior to GIFs because they are vector and won’t loose any quality no matter what the resolution.

    You have a large collection of GIFs, and no one but Pioneer Valley will ask you to upgrade those images… but you should upgrade all your software to the latest versions whenever possible (and whenever stable by the developer). It’s safe, it’s smart, it’s secure, and it will open more doors for you to do more advanced things. The problem with advanced things is that they are not fully compatible across all browsers/devices, but that is what graceful degradation is for!

    You have a large collection of GIFs, and no one but Pioneer Valley will ask you to upgrade those images

    This can be done quite well and easily using a script and GIMP, which is free also, not to mention many other image post processing programs. Since they are all being added to WP now, now is the time to do it, IMO. It need not affect their use elsewhere (the other sites). If we had old HTML sites and wanted to import them all to WP, we could do just that with a proper parser, using a string replace in MySQL to update the paths and file extensions. Such could have been done for a large site in short time.

    We will end with one last caveat. Animated GIF’s tend not to follow rules of accessibility if they contain text that the user should (see or hear) access.

    Thread Starter Peter_Pan

    (@peter_pan)

    wpismypuppet: You have to understand that former “client side only coders” like myself never had to be concerned with PHP issues, and your simple solution of upgrading to the latest PHP was something that for all the length of this thread, I had to discover on my own I could easily do. Going back to the beginning, I simply raised an issue I didn’t understand, having seen similar complaints in the forums. For several messages there was no help actually addressing the problem, until someone (wpismypuppet I think) mentioned the “GD” problem, and suggested I install ImageMagick. It was a pure accident I discovered the flaw in my PHP GD library was already corrected in a newer version, which I had the ability to upgrade through my host’s Cpanel. So now looking back, I was just offering some reasonable warnings for others and possible fixes.

    You said it didn’t affect 98% of users? Well according to https://en.wordpress.com/stats/, 2% would still be well over a million people. So if simple things like warning a user when an old version of PHP being used on a GIF , or “falling back” to never processing the raw unsized image are not worth the effort for that 2%, that’s your opinion. Trust me, if I had a million customers on Win 3.11, I’d address it. To believe that the GIFs or old browsers are irrelevant because they are obsolete, and that users running into the problem are not even worth an automatic warning, that’s simply wrong. Insult me if you want, but we simply have different philosophies about coding in ever improving support for problems.

    Thanks Pioneer. This is getting off the topic, but I say GIF animations are still very useful, even beyond their entertainment aspect, and apparently still more highly cross-browser compatible than PNGs. I’ve never seen a problem with any browser rendering a GIF, but apparently PNG transparencies still don’t render correctly in some browser versions just a few years old. And besides browsers, many email programs never get upgraded by home users, and you’d be amazed how many email programs still render a PNG graphics as a broken image.

    I agree that looking for newer and better graphic formats when composing or acquiring new graphics is a good idea, and your point is very well taken about the riskiness of putting text in a GIF. As you can see, I’m just a person concerned, maybe overly so, with backward compatibility. Media incompatibilities will always be a headache, with plenty of bigger problems than GIFs. I have some sites going on 13 years old that still render fine, but for media… OUCH! Every couple of years I have to go back and address all the new video or audio incompatibilities. Last time it was when FLASH was supposedly going to become universal. Oh well!!! So I’m glad for HTML-5, but jhave a lot of work to do to implement all the file conversions. And I can only hope SOMEDAY all browsers will natively handle a few sound and video formats as well as they all now support GIFs! ??

    I have blogged on 3 different platforms, the other 2 do not exist anymore. I am glad to feel that WordPress will be here for a very long time at least!

    So, I get your point well and do truly understand your points. Who knows whether or not by tomorrow, in a few months, a few years or a few decades if this whole thread will be moot? I’m thinking not too many years…Change appears constant but the improvements are vast.

    I am having the same problem so you are not alone…As I do not have access to my hosting service or FTP this maybe a little be annoying…I am just updating the website for a non-profit that I volunteer for on the side…I didn’t even make or run the site last year…I hope it gets fixed soon as I have no idea how to contact the hosting service of the site…

    I’m having the same issue. Hope Pioneer Valley Web Design stops arguing with you, btw. Sort of pointless. This sort of issue is a perfectly good thing to ask a fix for. Users have needs.

    Anyway, it’s definitely a real problem, and while it might be because of PHP, perhaps there’s a solution someone far smarter than I am can come up with.

    Fingers crossed.

    Thread Starter Peter_Pan

    (@peter_pan)

    tim— As it turned out, my particular hosting company does let me switch to newer (or older) versions of PHP, and doing so did fix the problem. But you’re quite correct noting the unwillingness to support. And while I wouldn’t expect the authors or coders to try to actually write a workaround for a flaw in a dated PHP Gd library, I don’t think building in an alert when a version of GD known to cause issues will likely be a headache to the user. The refusal to consider THAT is very telling. There were some other workarounds that gave me reasonable success involving plugins and such. And if you’re really sneaky, you can replace the badly created images for the other sizes with identically named filenames, of images you prepare and resize yourself, using them as a guide.

Viewing 15 replies - 16 through 30 (of 31 total)
  • The topic ‘Gif Transparencies not transparent’ is closed to new replies.