Rapls PDF Image Creator – PDF Thumbnails & Featured Images

Списък с промени

1.4.47

• Added: where this server renders PDFs, the Status tab and Site Health’s Info tab say what to ask your hosting provider about the Ghostscript vulnerability CVE-2026-39919. The plugin cannot tell whether the server’s Ghostscript is fixed, so it does not judge it
• Added: a FAQ entry about CVE-2026-39919: what it is, why PDFs reach Ghostscript, what to ask the host, and what denying PDFs in policy.xml stops

1.4.46

The optional add-on
* Added: the optional paid add-on, Rapls PDF Image Creator Pro, is mentioned in five places only (the Plugins screen row, a card at the bottom of the Settings tab, the Status tab as one of three options when this server cannot render PDFs or a small box when it can, and under the page-number field after it is changed, until dismissed); nothing in this plugin is limited, and the filter rapls_pdf_image_creator_show_upsell, returning false, removes all of them
Choosing a PDF as an image
* Changed: PDFs with a thumbnail are offered in WordPress’s own image pickers only – the image, gallery and Post Featured Image blocks, the block editor’s featured image, and the classic editor’s „Set featured image“ and the featured image view of „Add Media“. Other plugins’ image pickers, core pickers that also take other media such as Cover and Media & Text, and the classic editor’s „Create Gallery“ (whose [gallery] shortcode shows images only) are not given PDFs. The filter rapls_pdf_image_creator_pdfs_in_every_image_picker, returning true, offers them in every picker that asks for images, as up to 1.4.20
* Fixed: a PDF in a gallery block, or chosen at a size its thumbnail has no file for, shows the thumbnail instead of a broken image
* Fixed: a PDF is offered only when it has a thumbnail; one whose thumbnail could not be made, or was deleted from the Media Library, is not
* Changed: a PDF dropped or pasted into the block editor is no longer turned into an image block. WordPress’s image block cannot upload a PDF, so the upload failed; it now becomes a File block, as without this plugin. To show a PDF as an image, choose it in the image block’s Media Library tab
* Changed: with Auto Generate off, the image block’s upload tab says beforehand that a PDF uploaded there gets no thumbnail, and one uploaded there by mistake can be deleted again from the notice that says so
* Changed: in the REST API, a generated thumbnail’s source_url and link are its own, as WordPress defines them; the PDF is given in rapls_pic_source_pdf_id and rapls_pic_source_pdf_url. Each size’s URL is now built from the image’s own URL, so it follows a CDN or offload plugin that rewrote it
* Fixed: an image that another plugin attached to a PDF is no longer taken for this plugin’s thumbnail
* Fixed: hiding generated images applies only to the Media Library’s list and to the media window (wherever it is opened), and no longer changes other queries in the admin or their search conditions
* Fixed: another plugin or theme asking for a PDF’s image with an empty or missing value, or handing WordPress’s media filters something unexpected, no longer stops the page with a PHP error
* Changed: the Media Library’s list view reads the PDFs’ images in one query, instead of one for each row
* Changed: after „Regenerate Thumbnail“, the Media Library comes back to the page, search and filter it was on, and a failure says why, with a link to the Status tab for administrators

Bulk Generate
* Fixed: the Media Library is read 200 PDFs per request, for the scan, the statistics and finding the next PDF, so large libraries no longer run out of memory or time. The statistics are read only when the Status tab is opened, and no longer on every visit to the Media Library
* Changed: Stop says it stops after the current PDF, and Continue carries on from the next one. Stop pressed while the next PDF is being looked for no longer starts drawing it
* Changed: the settings tabs and the progress are announced to screen readers, and the tabs move with the arrow keys, Home and End
* Fixed: a library whose PDFs are all in the trash says so, instead of suggesting another plugin is filtering the list
* Changed: with „Include existing“, finding the next PDF reads one row instead of 200

Making the thumbnail
* Fixed: a blank page drawn as transparent is now recognised as blank, so the retry for blank pages runs for it too, and a page that is blank is reported as such
* New: a page number past the end of the PDF fails with its own reason, which says how many pages the file has, and is not retried. The pages are counted from the PDF’s own page tree, which is not trusted for anything else: having Ghostscript count them draws every page, and nothing bounds how many a file holds. A PDF that claims more pages than it has, had pages deleted when it was last saved, or keeps its page tree in compressed object streams, as many recent PDFs do, gets the ordinary failure reason instead
* Fixed: an error from ImageMagick while drawing a page is reported as a drawing failure, not as a server that cannot render PDFs
* Removed: the retry that read the whole document when the chosen page came back blank. It never rescued a page, and a PDF that understates its page count could make it draw every page – 954 MB for one 60-page file. A blank page is still tried once more with Ghostscript’s transparency handling switched off
* Fixed: a page is drawn at a lower resolution when it would come out larger than 40 million pixels, or larger than this server’s own ImageMagick limits on width, height, memory and disk. Its size is read from the PDF’s page boxes, compressed object streams included, with the file read token by token as a PDF reader reads it, so that no key, string or comment can hide a page from it, and with limits on how deep, how long and how many of anything it reads, so that no file can exhaust PHP’s memory or stack while it is read; a page they cannot vouch for – a box whose numbers are too large to hold, or /UserUnit, among them – or one in a document with a page over the limit, is drawn small to measure it first. Where the page sizes can be read from the file, nothing in a PDF is drawn when a page in it is too large even at the lowest resolution, since that page would be drawn before any limit could refuse it: an ordinary page beside it is refused with it. A PDF portfolio, which holds other files that Ghostscript draws in place of its own pages, is not drawn either, and says so. A PostScript or EPS file, which Ghostscript draws as it does a PDF, is bounded the same way – found by its first bytes or by its name, XPS and PCL included – and so is any file that does not start like an image ImageMagick reads by itself; images are read as they are, as before, even one named .pdf. A page too thin to measure, in a PDF with a page far too large to measure it more finely or whose largest page size cannot be read, is not drawn, and says so, with the resolution it was measured at. A small PDF with a 200-inch page used to take 76 seconds and 2.9 GB; it now takes about two, and a 100,000-point page hidden in an object stream about one and a half. A page too large even at the lowest resolution is refused with its own reason. The filter rapls_pdf_image_creator_max_render_pixels changes the limit
* Fixed: the Page Selection test on the Status tab now asks for a page by number, as making a thumbnail does
* Fixed: numbers that a filter hands back as text are made whole numbers, and an error raised during conversion is a failed conversion, not a broken upload
* Fixed: the list of functions a host disables is read the way PHP reads it, so the blank-page retry is no longer turned off by a name PHP does not disable
* Fixed: an image handed over through a filter to be finished is no longer read again as a PDF
* Fixed: a thumbnail larger than 2560 pixels on either side, which WordPress saves as a smaller „-scaled“ copy, no longer fails every time; nor does a thumbnail on a site that has WordPress convert uploaded images to another format
* Fixed: GS_OPTIONS that the site already sets are kept, with -dNOTRANSPARENCY added to them for the retry, and are put back even when the request stops part way, at a time limit
* Changed: the rapls_pdf_image_creator_ghostscript_options filter takes only -q, -dSAFER and switches that set a value (-dNAME, -dNAME=value, -sNAME=value), and none that loosens Ghostscript’s SAFER mode, sends its output elsewhere, points it at files on the server, or changes the page drawn, its size in pixels, how much is drawn to make it, how many copies, which of Ghostscript’s PDF interpreters draws it or how much memory Ghostscript holds for it. A switch it does not take is left out of the retry, which runs with the rest, and the error log names it; a value with characters other than those switches are made of, or one with nothing left but -q and -dSAFER, turns the retry off
* Changed: the page count is read from the PDF itself where it can be, instead of having Ghostscript go through the whole document
* Fixed: a request that stops while drawing, at a time limit, no longer leaves an empty image file behind
* Fixed: when the server check fails for a reason of the moment – Ghostscript stopped by a memory or time limit – it is tried again after ten minutes and the Status tab says so, instead of every thumbnail stopping for twelve hours
* Fixed: on ImageMagick 6, a PDF that Ghostscript cannot draw is reported as a drawing failure, not as a server that cannot render PDFs

Settings and Status
* Changed: the CMYK warning on the Status tab is shown only when this server’s own test did not render CMYK correctly
* Changed: where this server or this WordPress cannot make WebP thumbnails, the WebP setting says so
* Fixed: placeholders in a Custom HTML template are escaped, so a title with a quote in it no longer breaks the markup
* Fixed: the thumbnail, clickable thumbnail and download link shortcodes keep several classes in their class attribute
* Changed: the shortcodes take a PDF’s ID only. The ID of a post, or of another kind of attachment, now gives nothing, where it could show that post’s featured image. The filter rapls_pdf_image_creator_shortcode_any_post, returning true, takes them again as up to 1.4.20, for readers who may see that post; a post of a type that is not public, such as a reusable block, only for people who can edit it
* Changed: the shortcodes show a PDF to visitors only when it is public. A PDF attached to a private or draft post is shown only to people who can read that post, and one attached to a password-protected post only to people who have entered its password or can edit it – including on another, public page
* Fixed: a shortcode with no class attribute keeps its pic-thumbnail class
* Changed: Insert into post, as a thumbnail or a title, follows the Link To and Size chosen in the media window (a Custom HTML template decides its own links). The plugin’s Link To and Insert Size settings are now where those choices start for a PDF, including one just uploaded in that window. An Insert Size the window does not list, such as medium_large or a theme’s size, is still used as long as the window’s Size is not changed
* Fixed: dismissing the notice about this server’s PDF support stays on the screen it was on
* Changed: the regeneration notices and Bulk Generate’s log put their sentences together the way the language does, not always with a space or a colon
* Changed: clearer wording on the settings screen and in the readme, and the Media Library column’s marks are read out to screen readers; the settings screen’s groups of options are named for screen readers and its colours are easier to read
* Changed: the settings screen’s script is loaded on the settings screen only
* Fixed: without JavaScript, every tab of the settings screen is shown, so the Status tab can be read, and the buttons that need JavaScript are replaced by a note saying what to use instead
* Changed: the review request, and the Support box on the Status tab, are not shown while this server cannot make thumbnails
* Fixed: Bulk Generate shows how many PDFs there are and how many are still to do separately, and a failure says why
* Fixed: saving the settings without some of the options – from code or WP-CLI – no longer stores empty values for them or turns the checkboxes it left out off; they keep what was saved
* Changed: a few queries fewer on every page load, and the Status tab’s „working“ colour is easier to read
* Fixed: replacing the plugin’s folder with a new version and activating it again runs the update’s own work, as an update from the Plugins screen does
* Fixed: without the settings screen’s script – blocked, or broken by another script – every tab stays in view

Keeping and deleting images
* Fixed: regenerating a thumbnail, deleting a PDF and uninstalling no longer delete a generated image that a post’s content shows – by its address in any size, in a retina (@2x) or WebP copy’s name, or under the name it had before it was edited, or by its ID in an image or gallery block or a [gallery] shortcode – which left a broken image in the post. The image is kept as an ordinary one, attached where the PDF was when the PDF is deleted. Names are compared whole, and in any letter case for the letters A to Z, whatever the database’s collation, so a post showing „annual-report“ does not keep „report“ and one showing „Report“ keeps „report“. A post’s excerpt counts too (a product’s short description), and so does a post in the trash, which can be restored; revisions and drafts saved automatically do not. An image a post uses as its featured image is kept too, and uninstalling gives a post whose featured image was a PDF that PDF’s image. An image a page builder keeps in the content by its ID alone, such as [vc_single_image image=“555″], is kept as well: any number where an ID could stand – an attribute’s value, a JSON value, an item of a list divided by commas or by spaces – counts, which can keep an image a post does not show, and never deletes one it does. A name written in JSON with \u escapes is found too, a name with „–“ in it among them, which the block editor writes as \u002d\u002d. The database is searched with LIKE alone, not regular expressions, which MySQL 8 could stop on a long post and MariaDB could skip it. If this cannot be checked, nothing is deleted. Widgets are checked as well – block, Text, Custom HTML, Image and Gallery widgets; other settings and a page builder’s data kept outside the post are not
* Fixed: an image a post uses as its featured image is kept on uninstall even when the record of which PDF it was made from is missing
* Fixed: a thumbnail shared with a translated copy of its PDF is handed to that copy, and attached to it, when this PDF lets go of it – also when the PDF is deleted with „Hide Generated Images“ off – so the copy’s own regeneration or deletion still finds it
* Fixed: when another plugin refuses to let a regeneration delete the old thumbnail, it is kept as an ordinary image, instead of staying hidden with nothing naming it
* Fixed: deleting a generated image from the Media Library no longer leaves its PDF naming an image that is gone
* Fixed: when a PDF is deleted, an old thumbnail a regeneration kept is attached where the PDF was, and its image is kept as an ordinary one if another plugin refuses to delete it, instead of staying hidden and attached to nothing
* Fixed: when a PDF is deleted, a thumbnail of it that an earlier version left hidden, with nothing naming it, is handed to a PDF that names it or kept as an ordinary image, instead of staying hidden
* Fixed: an image is kept when a post shows its file name with one character written as an HTML entity, percent-encoded or as a JSON escape, or names its ID after a JSON escape
* Fixed: an image that an audio or video file uses as its cover is no longer taken for another PDF’s thumbnail, which left it marked and hidden
* New: a regeneration that kept the old thumbnail says so on the screen that ran it, and why: a post shows it (and still shows the old picture until it is replaced there), a post uses it as its featured image, another copy of the PDF – a translation’s – uses it, or whether anything uses it could not be told
* Changed: „Insert into post“ gives the image the „wp-image-“ class with its ID, as WordPress’s own insert does, so WordPress adds srcset to it
* Removed: the AJAX action rapls_pic_regenerate_thumbnail, unused since the Media Library’s own Regenerate link took over; and the insert keys the plugin added to wp_prepare_attachment_for_js, which nothing read
* Changed: the methods behind those two – MediaLibrary::ajaxRegenerateThumbnail() and Inserter::addInsertSettingsToJs() – and BulkProcessor::getPDFs() and getStats(), which Bulk Generate no longer uses, are kept, deprecated and hooked to nothing, for code that calls them

1.4.20

• Fixed: deleting the plugin from a multisite network now cleans up every site, each by its own „Keep Images on Uninstall“ setting. Before, only the site it was deleted from was cleaned up, and the other sites kept the plugin’s settings, its markers on PDFs and images, and – with that setting off – the generated images

1.4.19

• Fixed: whether an old or unused thumbnail was deleted is now judged by whether it is still there afterwards, not by what the deletion returned. Another plugin answering pre_delete_attachment with the attachment itself stops the deletion while looking like success, and the PDF then lost its link to an image that stayed in the Media Library. An attachment already deleted by something else is now counted as gone

1.4.18

• Fixed: Generator::outcomeFor() now forgets the previous attempt’s result as soon as a new generate() begins. An error thrown during the first checks of a new attempt left the previous result in place, where it could be taken for the new one

1.4.17

• Changed: an error thrown by code listening to rapls_pdf_image_creator_after_generate or rapls_pdf_image_creator_generation_failed is no longer caught, as it was in 1.4.15 and 1.4.16; it reaches the caller, as errors in WordPress hooks normally do. WordPress does not tidy up a hook after an error inside it, so carrying on quietly left that hook in an unfinished state for the rest of the request
• Added: Generator::outcomeFor( $pdf_id ) says what the last attempt for a PDF came to in the current request – made or not, the thumbnail ID, and the failure code and message. It is recorded before the actions run, so it does not depend on which listeners run first or whether one throws
• Fixed: when a new thumbnail did not come out as drawn and another plugin refused to let it be deleted, nothing said so. This is now written to the PHP error log

1.4.16

• Fixed: an error thrown by code listening to rapls_pdf_image_creator_generation_failed no longer replaces the failure it was told about. The failure is still recorded and returned as it was, and the error is written to the PHP error log
• Fixed: when a new thumbnail could not be recorded for its PDF and another plugin refused to let it be deleted, nothing said so. This is now written to the PHP error log
• Fixed: the Settings class’s save() now reports success when the stored settings hold the values given, including when they already did, and saves onto the settings as they are stored now rather than a copy read earlier

1.4.15

• Fixed: when a new thumbnail had to be removed again and another plugin refused the deletion, its image file was deleted anyway and the attachment was left pointing at nothing. The file now stays with the attachment
• Fixed: a new thumbnail is now checked to point at the image file that was drawn. When a filter made it point at another file, it was reported as made; it is now pointed back and removed, and if it cannot be pointed back nothing is deleted, since that other file may belong to something else
• Fixed: the rapls_pdf_image_creator_thumbnail_format filter now also decides the file extension and MIME type. Before, it changed only the image data, so a PNG could be saved as .jpg and registered as a JPEG
• Fixed: an error thrown by another plugin while a thumbnail was being drawn no longer leaves an empty image file behind, and an error thrown after a thumbnail was made no longer makes it look as if it had failed
• Changed: when an old thumbnail cannot be deleted after it has been replaced, this is now written to the PHP error log

1.4.14

• Fixed: when a regeneration could not save the new featured image, the PDF’s own thumbnail record is now put back exactly as it was. A featured image chosen by hand was written into it instead, and was then taken for a thumbnail this plugin had made
• Fixed: a regenerated thumbnail whose image metadata could not be made is no longer reported as made; the previous thumbnail is kept. The Media Library did not show such a thumbnail for the PDF
• Fixed: two regenerations of the same PDF in the same second could write the same image file and register it twice, so deleting one removed the other’s image. Each now takes its file name before drawing into it

1.4.13

• Fixed: a regenerated thumbnail is now kept only once the marks that tell the plugin it made the image, and the image’s metadata, have been saved. When they were not, the image was reported as made but could never be removed by a later regeneration
• Fixed: with „Set as featured image“ on, a regeneration whose featured image could not be saved now fails and keeps the previous thumbnail. Before, it reported success and the PDF was left with no featured image
• Fixed: when an old thumbnail could not be deleted, the PDF now keeps its link to it, so the image is not left behind with nothing pointing at it

1.4.12

• Security: the Media Library’s „Regenerate Thumbnail“ request now checks that the user may edit that PDF, as the link itself already did. Before, any user who could upload files could regenerate – and so replace the thumbnail of – a PDF they could not edit. The Bulk Generate requests now require the same permission as the settings page they are on
• Fixed: regenerating a thumbnail no longer deletes the old one first. The new thumbnail is made and recorded, and only then is the old one removed, so a PDF whose new thumbnail cannot be made keeps the one it had
• Fixed: regenerating or deleting a thumbnail no longer removes a featured image the PDF was given by hand. Only a link that names the generated thumbnail is removed
• Fixed: a few messages on the Bulk Generate tab and the Media Library were shown in English whatever the admin language

1.4.11

• Changed: the FAQ says which generated images uninstalling keeps – those used as a featured image or shared with a translated copy of the PDF – and that an image placed inside a post’s content is not detected, so „Keep Images on Uninstall“ should be turned on first in that case

1.4.10

• Fixed: uninstalling the plugin (with „Keep Images on Uninstall“ off) no longer deletes a generated thumbnail that another post uses as its featured image, or that a translated copy of the PDF shares. Those are kept as ordinary images, as regenerating and deleting a PDF already did since 1.4.8. When this cannot be checked, no image is deleted. An image placed inside a post’s content is not detected; turn on „Keep Images on Uninstall“ to keep those

Earlier versions

The changes in 1.4.9 and earlier are listed on the plugin’s page: https://raplsworks.com/plugins/rapls-pdf-image-creator/