Database prefix

I’m closing this because, upon deeper inspection, I found where $wpdb->prefix was being added to the table names, in Run_Library.php.

There’s a bunch of other small issues that a PHPCS pass is finding, so I recommend using a ruleset like https://github.com/10up/phpcs-composer to audit the plugin and determine what errors are worth your time and attention.

Examples of errors include:

• direct filesystem access instead of using WP_Filesystem methods, including the use of unlink() to try to delete a file. I’m not sure that that would actually work on VIP’s Filesystem. https://docs.wpvip.com/vip-file-system/media-uploads/
• storing log files within the plugin’s own directory, which may not work on hosts with read-only filesystems. These files should probably be stored in get_temp_dir() or a subfolder thereof. (Note that VIP’s Filesystem doesn’t actually have subfolders)
• using esc_html() in place of esc_html__() in Scan_Library.php
• using esc_attr() in place of est_url() for URLs in attributes
• using esc_html__() in place of esc_attr( __() ) in Admin_Library.php
• using in_array() without strict comparison
• == loose comparisons
• missing wp_unslash() when handling $_REQUEST
• random spare ; in library/_helpers-library/helpers-library.php

Thanks for the promise to look into this!

I have sad news to report: This plugin silently fails on VIP GO hosting. I’m scanning four custom post types, the Media Library, and the Pages post type, with >10,000 posts across a decade, with known missing alt text.

Clicking “Start Scan” causes it to start scanning, but nothing happens in the admin. In the network tab, I see a bunch of POST requests to /admin-ajax.php which receive the following response:

{"done":0,"total":0,"remaining":0,"percent":0,"startDate":"","endDate":"","currently":"","scan_type":"","scan_portion":"","scan_sub_portions":[],"scan_specific":"0"}

The plugin’s notification icon lights up, and says “A full scan has failed (full->->all->0).”

After activating the plugin’s debug mode and re-initializing the scan, the scan still fails. The plugin’s own “Logs” tab says:

Debug log not found.

The WordPress error log says:

PHP message: PHP Warning: file_put_contents(/var/www/wp-content/plugins/fix-alt-text/logs/1-debug.log): Failed to open stream: Read-only file system in /var/www/wp-content/plugins/fix-alt-text/library/_helpers-library/inc/Debug_Library.php on line 382

So it looks like this plugin has at least two compatibility issues with WordPress VIP:

1. Nonstandard logging: you should write to the WordPress error log in addition to trying to write to your own log
2. Whatever’s blocking the scan.

For the debug log, I’d recommend doing two things in your function which handles debug logging:

1. Allow that function to fail gracefully if it can’t write to the directory. It shouldn’t cause any errors.
2. Also write a copy of the message to the default WordPress error log, using the function error_log()

For queueing the scan, I’d need to know more about what data you’re storing to give a firmer recommendation, but: Can you save that data as a transient? https://developer.wordpress.org/apis/transients/

I was going to recommend you use get_temp_dir() to find a directory which will be writeable, or wp_tempnam() for a writeable temporary file if that file only needs to persist during the current script execution. However, https://docs.wpvip.com/vip-file-system/local-file-operations/ says that this directory and its files cannot be assumed to exist after the current request, since subsequent requests may be served by different server containers.

You might try wp_upload_dir(), which does include the current site ID and yyyy/mm in the path. If you’re only allowing access to the multisite tool from the network admin, or if individual sites can only perform scans on themselves in a multisite context, then that might work.