twykr

If it helps – I ran into this issue for a client just recently as well, and it turned out that the issue was the SSL that we added to the site. The DM plugin does not update the links associated with each download for SSL – and it cannot handle the http->https redirect without breaking (ala “Download not found” / “Page not found”). If you’ve recently added SSL to your site, that may be the cause. I’m guessing it’s the same if you’ve changed your domain at all (added / removed a sub-domain, etc).

What I did to fix it was to use the “Better Search Replace” plugin to search&replace all “https://www.clientdomain.tld” links with “https://www.clientdomain.tld” – and that made the DM plugin happy again.

FWIW – HTH ??

Hey Robbie –

I’m not the developer of this plugin (although I’ve been considering forking it to a new plugin, if the author is no longer supporting it) – but I believe if you export the ACF definitions to PHP, and then write some PHP code to “auto-populate” the tag it field as you wish from the WordPress default tags, it should work the way you want.

Basically, it’d be similar to the solution I mentioned on this thread (at the bottom):

https://www.ads-software.com/support/topic/remove-auto-suggest-drop-down/

Hope that helps!

-twykr

Addendum thoughts: A couple other features I’d suggest:

1. An “import ONLY from these domains” list option, as sometimes it’ll be easier to specific exactly which domains from which to import rather than a long list of other sites to block.

2. The ability to ONLY do images, or ONLY do PDF files, rather than doing both all of the time.

FWIW,
twykr.

Hi again –

Okay – just noting that I ended up exporting the ACF definition to PHP code, and putting it into the child theme’s functions.php file. From there, to get the suggestions that I wanted, I manually queried out the past entries from the database, and added them to the ACF definitions myself (in the “available_tags” section). Here’s some code snippets, if it helps. NOTE: I’m using the generic field name of “acf_field” in my code – you’d want to replace that with your actual ACF field name / handle in the appropriate places… and you should *not* copy / paste the ACF PHP code itself, as that will not work:

// Pull any previous "acf_field" values from the wp_postmeta table
$query_acf_field = "SELECT DISTINCT meta_value FROM " . $wpdb->prefix . "postmeta WHERE meta_key = 'acf_field' ORDER BY meta_value ASC";
$pull_acf_field  = $wpdb->get_results($query_acf_field);
// declare the var and clear out any past information - just to be sure
$acf_field_values = '';
// loop through the query results, and add them to the list - each on their own line
foreach ($pull_acf_field as $by) {
  $acf_field_values .= $by->meta_value."\n";
}

And you put the output from the above query in your ACF PHP definitions, like so:

// EXAMPLE ONLY - don't copy / paste this, as it won't work. 
// Instead, look in your ACF PHP code, and find the entry that uses "tag-it" as the "type"
array (
	'key' => 'field_abcdef1234567',
	'label' => 'acf_field',
	'name' => 'acf_field',
	'type' => 'tag-it',
	'instructions' => 'Add any acf_field information you wish to appear publicly',
	'required' => 0,
	'conditional_logic' => 0,
	'wrapper' => array (
		'width' => '',
		'class' => '',
		'id' => '',
	),
	'available_tags' => $acf_field_values,
),

Note that you should be able to enforce no results for suggestions by simply having:

‘available_tags’ => ”,

HTH,
-twykr

• This reply was modified 7 years, 10 months ago by twykr.
• This reply was modified 7 years, 10 months ago by twykr.
• This reply was modified 7 years, 10 months ago by twykr.
• This reply was modified 7 years, 10 months ago by twykr.

Interesting – I was going to ask the opposite. I’m wanting the auto-suggest functionality to work (listing suggestions of past tags entered), but it’s not working for me.

Rather than completely remove such functionality, I think it would be best as an option that one could turn on and off – so that both of us could get the functionality we needed ??

I’m going to dig into the plugin and see if I can figure out why it’s not working for me (i.e. listing possible suggestions of tags previously entered), and maybe will find a way to offer an on/off switch in the bargain ??

-twykr.

Addendum / update:

Apologies – I realized this morning that, after the last update, the issue is with NextGen Pro and not with NextGen Gallery itself.

I am now able to get it to run without the Pro enabled, although I have to reconfigure all of my galleries to get that to work…

Sorry!

Hi Cais –

I’ve setup a fresh / clean Ubuntu 16.04 LTS box for testing my Photocrati / NextGen setup before I upgrade my actual hosting server, and there are plenty of errors. The primary one for NextGen Gallery is:

Deprecated: Non-static method NextGEN_Gallery_Pro::load_product() should not be called statically in /-{snip path}-/wp-includes/plugin.php on line 525

And the same issue shows up separately on individual gallery pages (separate example of the same type of deprecated code problems):

Deprecated: Non-static method M_NextGen_Pro_Ecommerce::get_checkout_page_url() should not be called statically in /-{snip path}-/wp-content/plugins/nextgen-gallery-pro/modules/ecommerce/module.nextgen_pro_ecommerce.php on line 705

(Those are without Photocrati by the way, which is completely broken on PHP7 – and I realize a wholly separate issue).

I would note that with the latest release (v 2.1.43), I am now able to see the individual images for the galleries load (they didn’t previously) and get the lightbox functionality to trigger – although positioning is pretty off… but that I can fix with CSS adjustments if necessary.

twykr.

No, NextGen Gallery does not (yet) function with PHP7.

The plugin is built to require PHP functionality that has been deprecated in the newest version of PHP, and the developer are working on rewriting the functionality to support the changes (but haven’t finished yet, apparently).

If you need to use NextGen, or are considering upgrading a site that uses it to PHP7 – I’d recommend you hold off until the NGG developers have finished recoding the plugin to be PHP7-compatible.

@nielsff – yes, you can download the previous version of the plugin from the “Developers” page on their WordPress Plugin page:

https://www.ads-software.com/plugins/wordpress-seo/developers/

Scroll down a little, and you’ll see a section named “Other versions”.

HTH,
twykr.

Hey all –

I’ve finally figured out the source of that content, albeit not how to fix it. I’m guessing you all are also using a theme from Elegant Themes, that use the “Divi” page builder? Could you confirm this?

It appears that the “layout_type.sitemap.xml” is coming out of the “Divi Library”, where the custom (dynamic) page template layouts are stored, and it doesn’t appear that both however EG / Divi setup that system is complete (missing a date), and Yoast SEO doesn’t take that type of setup (however Divi is doing it) into consideration – so it’s not something that you can disable.

I’m still seeing if I can track down something to block that output – but in the meantime, a work-around option is to try out / use the “Google XML Sitemaps” plugin, which doesn’t seem to suffer from the same oddness.

FWIW,
twykr

@jbesa –

I’m having the same exact problem ??
I’m currently looking into a quick fix, but would appreciate it if someone else had a proper solution to this…

Yoast SEO v.2.3.5

twykr.

Hey garyweldy –

I went into my cctm_data file …

Just to be sure – you grabbed the block of code from your database backup, and not a file, right?

Also, make sure that the database backup you used is old enough. I believe the backup would need to be, at a minimum, over a week old (8+ days old or older) to contain the missing data that you need.

Hope that helps ??
twykr

Hey –

So, this question is asked on several threads, but since this one has no answer, I’ll post my experience here.

Ran into this exact issue for one of our clients, after they upgraded to the broken version of this plugin – and finally figured out a way to restore the settings / custom field types that had already been declared… IF you have a backup of your database settings from before the bad plugin update.

So if you happen to have a database backup from before this unfortunate incident, then restore it somewhere else other than your production environment (personally, I copied the raw MySQL files for the db in question to my local machine, and added them to my local MySQL install), and do a search in your “wp_options” table for the option_name of “cctm_data”. Grab the “option_value” contents (a large JSON block) from that entry. Then go to your production environment, lookup the same value and replace the contents with the block you recovered from the backups.

And that should fix things.

Note that I believe that it shouldn’t matter how long ago your database backup was made – as long as you haven’t changed or added any custom content types / fields since that backup was created.

Hope that helps!

twykr.

Hey all –

Ran into this same issue, and finally figured out a fix. The problem is that the busted version of the plugin improperly modified the “cctm_data” JSON block (option_value) in the wp_options table (*note: table name may differ, if you’re using a custom or random db table prefix)

So IF you happen to have a database backup from before this unfortunate incident, then restore it somewhere else other than your production environment (personally, I copied the raw MySQL files for the db in question to my local machine, and added them to my local MySQL install – but don’t restore the db to your live website, or you’ll lose ALL updates to your website since that backup!!), and do a search in your “wp_options” table for the option_name of “cctm_data”. Grab the “option_value” contents (a large JSON block) from that entry. Then go to your production environment, lookup the same value and replace the contents with the block you recovered from the backups.

And that should fix things in the admin.

Note that I believe that it shouldn’t matter how long ago your database backup was made – as long as you haven’t changed the custom content types / fields that you’d previously declared since the backup in question was created.

…and if you have no backups of your website – then that’s a whole other problem in and of itself… but it’s probably possible to hand-reconstruct the proper entry from the existing (bad) one. I’ll leave it to the author or someone else to figure that out, though, if that’s really needed by someone.

Hope that helps!

twykr.

Hi all –

Ran into the same issues with the Sermon Manager plugin while using the WordPress SEO plugin. Was trying to generate a sitemap XML file for Google, and was constantly getting the error:

ERROR: This is not a valid feed template.

Turns out the problem is that the sermon manager plugin has a bad rewrite declaration in the code of the following file:

…/plugins/sermon-manager-for-wordpress/includes/podcast-functions.php

specifically, lines 132-139:

131 // Custom rewrite for podcast feed
132 function wpfc_sermon_podcast_feed_rewrite($wp_rewrite) {
133         $feed_rules = array(
134                 'feed/(.+)' => 'index.php?feed=' . $wp_rewrite->preg_index(1),
135                 '(.+).xml' => 'index.php?feed='. $wp_rewrite->preg_index(1)
136         );
137         $wp_rewrite->rules = $feed_rules + $wp_rewrite->rules;
138 }
139 add_filter('generate_rewrite_rules', 'wpfc_sermon_podcast_feed_rewrite');

The problem is that the rewrite specified on line 135 basically takes over ALL files with an XML extension, which is definitely not right. Personally, I’ve disabled this code on at least one of the sites we manage, as the SEO functionality outweighs a podcast feed.

For a permanent fix, I’d suggest that the plugin should have a hard-set prefix for it’s own podcast XML files? For instance, changing lines 134-135 to be something like:

134                 'feed/smpodcast-(.+)' => 'index.php?feed=' . $wp_rewrite->preg_index(1),
135                 'smpodcast-(.+).xml' => 'index.php?feed='. $wp_rewrite->preg_index(1)

So that it doesn’t interfere with other XML feed files or declarations that people might use… but I’ll leave the choice on that approach vs. another up to the plugin author.

For now, you can also solve this issue by commenting out line 139 (that activates the XML filter being declared), and then re-saving your permalink settings in WordPress.

Hope that helps!
twykr