susanwrotethis

1. Well, no, seeing as it’s a problem in WP Admin, specifically on the post.php screen.
2. It may help you to know that this is not an issue for higher-level roles (Editor, Administrator) but is for custom roles. We have a series of custom roles that have Editor-level access to create, edit, delete, and see private entries, but only for the specific custom post type the role is associated with. (It doesn’t seem to be a CPT issue, as the custom role for editing Posts is having the same problem.) If you recently made a change involving a current_user_can() check, it may be looking for standard caps only. I reported similar issues to another plugin at the same time where that was the case.

That’s really helpful and informative. Thanks so much. Sometimes I give demos to executives who know just enough to want to go down rabbit holes over irrelevant details. The fewer “why is that showing an error?” questions I need to field, the shorter our meetings are. ??

Appreciate all you folks do. Thanks again!

Susan

Hi Kris, I found last night that it doesn’t even have to be a custom role (we roll our own, BTW — no pun intended). An Author or Contributor role experience the same issue. This is re the original querySelector issue. As regards the additional info I sent, I’m investigating further, but I’m increasingly convinced this isn’t related to Smush and was coincidental that it came up at the same time.

Thanks!

Susan

• This reply was modified 8 months ago by susanwrotethis.

Additional info: the rest_forbidden_who and rest_forbidden_context errors do not appear when all plugins other than Smush are deactivated, so I am looking elsewhere in regards to those. The querySelector error remains, however.

Thanks, I already implemented the patch. Going to trust to menu_order for now. Seeing as that field has been in the page-attributes meta box for pages for as long as I can remember, I can’t imagine it being deprecated without notice.

Answer found after a deep dive. Trac ticket opened five years ago (https://core.trac.www.ads-software.com/ticket/46264) and it has never been resolved. Sigh.

I’m working on something similar right now, and I found a way. Here’s a sample function:

function my_function_makes_page_public()
{
	global $post;

	if ( empty( $post ) || 'mypageslug' !== $post->post_name ) return;

	add_filter( 'aioi_allow_public_access', '__return_true' );
}
add_action( 'wp', 'my_function_makes_page_public' ) ;

In this case, if the slug of the page I want to remain public is the slug of the current page, it sets the access to public for this page. The plugin returns without doing anything. You can adapt this to check multiple pages using page slugs, IDs, or some other characteristic unique to them.

The Smush update that just came out seems to have fixed the problem. I’ll continue checking my own plugin code to eliminate the likelihood of future conflicts.

Thanks!

Thank you! It does. I appreciate your timely help.

Hi there, I think the issue may be the form action. I’m not sure that WordPress is finding mailer.php. The path to the script needs to be updated.

You may want to consider using a contact form plugin. There’s some great free ones out there. This isn’t a reflection on your work in any way — just that it would take less time to install the plugin and add a contact form than adjusting your code to work within WordPress.

Hi there, I don’t know that I can offer much to help, but: have you bounced this off your host’s support to see if anyone else has reported a problem?

And is there anything that makes this site stand out from the others — such as its age, the theme/plugins it uses or whether it was a fresh installation versus something that was migrated from another location? Are there any major differences in the .htaccess files? Anything that they have in common is most likely something you can rule out.

I’m looking at https://yournameonit.us/shop/ from my computer and I’m able to see and interact with your products.

Are you saying the form and images are missing from https://www.yournameonit.us, or are they missing from https://yournameonit.us/shop/? The former is a basic site with placeholder content and the latter seems to be a fully functional site.

It’s not unusual for someone to have a WordPress installation in the root directory and another in a subdirectory; sometimes this is by accident and sometimes it’s a temporary development environment.

If you want everything at https://yournameonit.us/shop/ to be moved to https://www.yournameonit.us, that should be able to be done. You may need to ask your hosting company for advice.

I’ve googled “td-mobile-plugin” fatal error and see other users have reported similar problems.

The response to a similar error four months ago was “It seems you will have to uninstall all other plugins before installing the mobile theme plugin. Please disable all other plugins and install the mobile thee first.”

I assume you’re paying for this theme. If you haven’t done it already, I highly recommend that you contact their support team as soon as possible.

Hi there, I haven’t found exactly this functionality on its own. Things like this may be available in some page builders — but they come with a lot of other parts and may slow down a site.

You may want to check out the Gutenberg plugin (https://www.ads-software.com/plugins/gutenberg/), which enables the ability to drag and drop images directly into a page. The WordPress core team is working toward making Gutenberg the new default interface, so it’s expected to become part of core, quite possibly within the next six months.

Hi there,

I found where the OCR text is being inserted into the database, but there’s no filter or action hook that will let you modify this action directly.

What you could do is to write a WP Cron job to periodically — how often depends on how quickly you need the info and the volume of files you’re handling — to turn the inserted text into the alt text.

Basically, the cron would execute a SQL query to find all the records in the wp_postmeta table where meta_key = ‘ocr_text’ and change the meta_key to ‘_wp_attachment_image_alt’, which is the name of the field the alt text is stored in. Some things you might want to have safety checks for are whether alt text is already set (in which case you’d end up with multiple alt text values for an image, which will create problems) and a check that the text isn’t too long for the field type.

If you could get the developer to add an action hook to the AnalyzeImage($image_id) function, right after: the line

add_post_meta( $image_id, ‘ocr_text’, $ocr_text, true );

you wouldn’t need to do this as a cron. You could write a function to change the meta_key value and add it to execute immediately after the ocr_text is inserted into the database.

This is a broad outline rather than a step-by-step how-to, but if you google WP Cron and WP Query, you’ll find additional details.