delwinv

Having no further discussion on this I assume the issue is closed.

Having no further discussion on this, I assume the issue is closed.

Hi medmic,

Sorry for the very long delay in responding to you.

I have added some debugging code to help resolve this issue in version 1.04 of the plugin. Please update to this version and try again.

The path of images is determined from the standard WordPress function wp_upload_dir() and the meta data of the image stored in the db, so I’m not sure why this is an issue, but I will investigate further. I myself have never tried this when organization of image path is by date, so there could definitely be an issue here.

Please stand by…

??

Delwin.

Hi diablolique,

Sorry for the long delay in response time. The only thing I can think of is an overloaded web and/or db server. If your response time on administering or displaying your site is slow this plugin will also be slow. Otherwise there *should* be not reason that it is be slow.

Sorry I can’t be of much more help without more details.

Delwin.

This plugin can only detect images used in Pages, Posts and Pods and cannot detect images used via shortcodes or through other plugins. For this reason the images are listed to you so that you can manually verify that they aren’t used prior to actually deleting them and the reason no automatic deletion is offered.

Please use this plugin with care and verify that the image is not used prior to deleting. This plugin is only meant as an aid to deletion and finding images that are used in the most common ways in WordPress.

Delwin.

Hi vanbax,

Sorry for the long delay in response.

In the list, any image that is determined to be in use cannot be selected by the checkbox next to it (the checkbox is disabled). The select parent unused option will select only those parent images that are unused – where the checkbox is enabled and the image listed in black. All others will remain unselected. Same goes for Select child unused – except it operates only on child images.

To manually select, remember that the image and checkbox will not be greyed out if it is an image you can select (it is unused).

Hope that helps,
Delwin

Hi Thalskarth,

Sorry for the long delay in respond time. I’m not sure why the plugin would report the images having been deleted but then show them again in the list. I would need to see the plugin in action on your site (or a copy of your site if you could bundle it up in a zip file and a db dump) to be able to diagnose the problem. I cannot guarantee any timeframe for being able to do this either, since this is a free plugin and my time is quite taken by my paid work.

anapest, if the upload directory permissions have been changed in a way that prevents the image from being deleted from the directory the plugin fails nicely and simply deletes it from the database so that you don’t have to deal with seeing it in WordPress anymore.

Delwin

Hi,

Thanks for the comment. I will look into support for Slider Revolution but support may be long in coming. I will have to determine where and how the images are referenced in the database by this plugin so will have to work with their developers. If they do reference by id this will not be easily possible.

Delwin.

The total is the number of parent images found in the database. Their could be images that are child images, but they are determined later in the code process and only on a per-page basis. So th 1012 is a count of parent images and their children listed on that one page. 7 of those parent and children are used.

Hope that helps and sorry for the LONG delay in responding
Delwin.

Hi, sorry for the long wait for a response!

The plugin determines the upload folder using WordPress’ wp_upload_dir() function, so any change to this dir performed in a standard WordPress manner is supposed to be taken into account. Can you tell me how you changed the upload directory? I can take a look and see why wp_upload_dir() might not be seeing it properly.

As for shortcodes and specifically image ids, this plugin does not search for images and their usage based on id. This would be a trouble-prone thing to do since the id would have to be searched within text that could contain those numbers naturally and the plugin cannot know of every sort of shortcode possibly added by other plugins. Unfortunately this means that usage of shortcodes within posts and pages is not supported and the image would be seen as unused.

Hope that helps and sorry I can’t be of better help.
Delwin.

Thanks,

This is part of code that exists from previous plugins on which this plugin is based and I had no need to look that closely at the code which was functioning. Thank you for making a more thourough examination and review of the code. Your help makes the plugin more robust.

Delwin.

You are correct, it does not look for image ids in a custom field. It searches on images that are used in posts, pages and Pods using their guid – the unique name given to the image. If you have done special programming to use the id of the image to have it appear on a page or post it will not be recognized by this plugin.

Hope that helps,
Delwin.

It can only determine if an image is used by normal WordPress posts, pages and Pods (when set up to use meta-data – the default installation). If your images are used in any other way the images will be listed as unused. That is why a screen presenting them is provided, so that you yourself can ensure that the image is not used.

Hope that helps,
Delwin

Hi Scott,

It wouldn’t be directly Pods related – that is it wouldn’t be Pods creating the issue. This plugin takes into account images used in Pods when Pods is not configure to use its own tables. The fact that Pods showed up in this thread is simply because of that – that this plugin does support Pods in that mode, not that Pods causes a problem.

Delwin

One possible issue could be the use of plugins other than Pods (or using Pods in table mode instead of meta mode). This plugin only identifies images that are in use by standard WordPress posts, pages and Pods content in meta mode.