mjayas
Forum Replies Created
-
Forum: Plugins
In reply to: [Password Passthrough] 2.0.0 not working with WordPress 6.8.1This issue seems to be a conflict between this latest update and two other plugins I use: Master Post Password plugin and Multiple Post Passwords. The previous versions of this plugin played nice with them.
I think the reason for the conflict is that 2.0.0 introduced this
ifblock…if ( $post && $post->post_password === $password ) {…which specifically looks for a match of the password in the URL to the one stored in
$post->post_password, unlike how 1.x handled this.Maybe in 1.x the cookie would be set even if the password didn’t match, and then the other plugins would handle checking the cookied password against their additional passwords? I’m not quite sure.
If there’s any way to restore compatibility with the other plugins, I’d really appreciate it. Either way, thank you for an excellent, simple plugin.
Thanks very much for the tip, @alexcozmoslabs!
Ran into same problem. Issue for me seems related to my WordPress installation not being in my server’s root directory.
As a result, the form on the Check & Log Email status page posts to the incorrect location:
<form action="/wp-admin/admin.php?page=check-email-status" method="post">In my case, the
actionattribute should post to/wordpress/wp-admin/admin.php?page=check-email-status(or, more simply,?page=check-email-status). When I manually correct that using the browser’s dev tools and then click ‘Send test email’, it works fine — no 404.It looks like (as of my posting this) line 98 of the plugin file Check_Email_Status_Page.php hardcodes this absolute URL for the
actionattribute instead of maybe leveragingplugin_dir_url()(or even just using the relative URL?page=check-email-statusas mentioned above).I think that would resolve this issue, at least in my case. attn: @mplusb
Yeah, de-activating and re-activating the plugin did the trick. Thanks for your help. Just a thought that you might want to consider adding a notice on the plugin page whenever you mention “migrating” that users should back up their databases before attempting to perform the “migrate” function. Indeed, I should have known this, but a reminder would have saved me a good chunk of time!
In any case, though, thanks again for your help and for the excellent plugin.
Sadly, my web host has confirmed that they have no db backup either. I’ll just need to recreate all those connections, alas. (This is obviously a bug you’ll probably want to investigate, as it could be a major issue for your plugin’s users!)
So, I guess I should just delete the plugin altogether from the WordPress control panel and just reinstall it, and the appropriate tables will be created?
Thanks for any additional help you can provide…
Thanks scribu — unfortunately, I’m not sure if I have backups from before I migrated. (Alas — I’ll make sure to do that in the future!) I’m checking with my web host to see if they have a backup. If not, am I out of luck altogether?
Hi scribu — thanks so much for the quick response. I don’t seem to have either of those tables (in my case, wp_[prefix]_p2p or wp_[prefix]_p2pmeta). Could the prefixes be part of the problem? Also, of the two types of connections I had registered, one was reciprocal.
For what it’s worth, I haven’t yet tried creating new connections to see whether they’ll save correctly, but I’m guessing that without those tables, they won’t save.
I’d really appreciate any further help you can provide! Thanks for a clean, simple, and powerful plugin. I hope I can get this working again quickly!
Forum: Fixing WordPress
In reply to: Enclosure Custom Fields Deleting!Check out this thread: http://ww.wp.xz.cn/support/topic/287260
Forum: Fixing WordPress
In reply to: Custom field with name “enclosure” disappears on saveI was having the same problem. Unfortunately, it looks like this behavior is considered a “bug fix”, and was coded right into WordPress 2.8. See the “bug” listed in WordPress Trac: ticket #6840. (I found this out by reading the changelog of the plugin ‘Podcasting’, under the header for version 2.2; it’s referred to there as the “enclosure prune” bug.)
A temporary fix I’m using is to add to the post’s body a redundant copy of the the URL I’m putting in the ‘enclosure’ custom field. A little messy, but it appears to do the trick.
Forum: Fixing WordPress
In reply to: You are not allowed to edit this page.Thanks for the fix, nsanden, and for the additional tips, cantemusdomino!
In case it’s helpful for others, my wp_[xxxx_]options table had a row with option_name of “wp_user_roles”, and a second row towards the bottom of the table with option_name “wp_[xxxx_]user_roles”. I first changed the former row, but that didn’t fix the problem. After changing the latter, it worked perfectly.
(Tip for newbies like me: the rows mentioned above didn’t appear on the first page of rows displayed in my MySQL admin tool; I had to click through a couple of pages to find them, and even still, they weren’t near each other.)
So, to summarize the fix:
- Go to the wp_[xxxx_]options table (where ‘xxxx’ is your table prefix)
- View all the data in that table
- Find the row with the option_name wp_[xxxx_]user_roles
- Edit that row, and replace the option_value for that row with what nsanden indicates above
- Save the changes to the row, and you should be all set.