Jo Landers

Hi, if you’re not seeing the url’s in the database, this plugin probably won’t help – it also searches the database for links, then tests if they are working. But if they aren’t in the db to start with, it won’t find them. I suspect you have a javascript file somewhere that’s NOT part of your database but has been inserted into your theme or the WP core, which is putting those URLS’s into your pages on the fly as they are served. Your best bet is probably to do a completely new, clean install into a new folder on your server, including reviewing all customized code you’ve created that you’re adding back to ensure it hasn’t been altered, and making sure that the wp-content/uploads folder only contains images, etc. Once you’ve tested and you know the bogus links are gone, replace the old site with the new one.

I think you mean what’s being talked about here:
https://www.projecthoneypot.org/ip_93.160.60.22 which wouldn’t have anything to do with this plugin.

same issue, the file is missing or not where the code expects it to be.

wp_mail is a built-in wordpress function; it is not declared or defined within the plugin; it is declared in pluggable.php`(part of the wordpress core). However, since this plugin depends on another function declared in that file, version 3.0 calls it if it hasn’t been loaded already.

Does Postman SMTP override functions in pluggable.php? If yes, try this within the file custom-dashboard-help.php:
Change line 42 from
cdh_admin_load()
to
add_action('plugins_loaded','cdh_admin_load');
and remove or comment out lines 96-98 (where the plugin checks for wp_get_current_user) and let me know whether or not that solves the problem.

The “open_basedir restriction” is specific to your hosting setup, and affects how files need to be included and loaded by other files and/or what the allowable ‘include’ path on your server is. Since the error you’re reporting has to do with how files are called, loaded and/or included, I really do think that’s the issue.

The only calls to markdown converter is an ‘if file exists’ or an ‘if class exists’ to see if the markdown converter plugin is available, during which the plugin checks a specific file path – only at run-time if requested (not during initialization, to avoid code bloat) and loads the file if it exists and is needed. Look at /includes/Jo_Landers_WP_Plugin_Admin/admin.php and you can see the calls in the function show_text_file(). The plugin should create a nicely formatted readme page if the code is available; otherwise it should just display the text file. If you disable the function call, you would have to view the file the same as any other plugin, in the WP editor or by downloading and opening with a text editor,

The code hasn’t been changed in a few years and nobody else has reported this error during that time. So either it is something specific to your setup, or I’ll be seeing more reports of this same error very soon b/c the plugin is using newly-deprecated code that no longer works as expected. But until/unless others are reporting the same issue or I’m able to replicate the same error myself, I have to consider it something specific to your installation.

You could try going into /includes/functions_admin.php and comment out echo $this->show_text_file(); or replace it with echo "please view the readme file using the plugin editor"; or something similar. If you do that, please update this thread to let me know if it worked. Since the function is only to display the readme file, it shouldn’t affect the core functionality of the plugin.

That looks like something within your host/server setup or WP configuration. Have you tried entering “open_basedir restriction in effect” into a search engine? There’s a ton of posts, including some from within the WP community, about that message and problems installing or uploading files.

Thank you, that did the trick!

Nothing has changed with the plugin (there were no recent updates and this is NOT a “new” behavior for it), so if you just updated it 2 weeks ago, you must have been using a very old version. With that in mind, is the rest of your site up to date? And what other code did you update at the same time? The plugin itself does NOT strip HTML but many other things can, including filters set up in your theme functions file, user preferences/permissions controls, etc. which can strip HTML on output or prevent it being saved to the database to start with.

As far as versioning goes, there are 2 older versions of the plugin in the WP repository, which are easily accessed thru the plugin’s WP page from the “developer” tab but I wouldn’t recommend using either one with the current version of WP. And your own backup files should also include earlier versions of anything on your site, including the plugin files and the database entry for your original instructions (before you edited them) with the related HTML.

If you mean “versions” like how a post can save multiple versions of its content – this is a plugin and when you change the settings, including what will display in the widget, you are NOT editing a post and don’t have the ability to use all the extra fields and settings available to posts, including having multiple versions of the post content. I don’t think anything in WP saves multiple versions of settings in the options table; the options table doesn’t include date stamps so WP wouldn’t know which version of the settings should be loaded. And having the plugin create a custom database table and including the code to use that instead of the regular options database table, simply to “version” the content of a single metabox would bloat the code for little reason. If you have long instructions that require a lot of HTML, don’t use the plugin for that – make them posts instead, put them into a special “help” category, tell your theme not to display anything in that category unless the user is logged in, then use the plugin – with some very short text and a link – to tell your logged-in users how to access that archive.

Thanks!

Thank you! I’ll look into incorporating that change into the next version. It looks like it will make this plugin load after all others? But I don’t think there’s any problem with doing that.

My plugin has nothing to do with user registration. I don’t know why you posted this question here; please explain.

Thank you restouffer for posting the fix. Folks, don’t forget you’ll need to redo that fix with every update until the author addresses it.

Hi Brent, yes, there’s no problems with 3.8. If you have the premium version the only issue is that you can not “force” it to be in the upper left on the dashboard b/c the “Welcome to WordPress” box takes the first position.

I will be uploading a new version in the next week or two. About half of my day-to-day work is bookkeeping, and unfortunately I didn’t finish testing the new version before I got caught in bookkeeping/tax prep overdrive. I’m just about past the worst of that, though, and getting back into coding.

Yep, last update seems to have completely broken this. All my internal links are being flagged as broken, with a “404 Not Found” message.

Log: === HTTP code : 404 ===

HTTP/1.1 404 Not Found
Date: Wed, 12 Feb 2014 15:31:25 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: https://www.hilltown-land-trust.org/xmlrpc.php
Link: ; rel=shortlink
Set-Cookie: PHPSESSID=adc9a2a2a10ba892e3baff73e19014b1; path=/
Set-Cookie: dgxdonate=adc9a2a2a10ba892e3baff73e19014b1; expires=Wed, 19-Feb-2014 15:31:26 GMT; path=/; domain=www.hilltown-land-trust.org
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Hi guys, I think this is b/c galinagk was logged into paypal recently enough that paypal knows it. If you delete the paypal cookies in your browser so the email address isn’t automatically filled in when you get to the paypal landing page, do you get all the credit card fields back?