DigTek

The update has corrected the problem.

Thanks for the quick response!

Thanks for taking the time to look into it, sometimes a fix is pretty easy, and sometimes not. In certain cases the missing scripts can be patched back in, but it is a double edged sword at best. V2 works great, so for the short term at least, that is an option.

I would agree, usually I can see why something did not work pretty easily, here is a screen, I am not sure what the DOM error is from, but it is there even will all plugins disabled, so is not due to Wicked Folders.

I have tried the latest version (saw the note about it being a fix), plus dev tools and debug mode, but neither show anything useful. I have it running on a clone site and the folder does not appear even when Wicked Folders is the only active Plugin.

• This reply was modified 10 months, 2 weeks ago by DigTek.
• This reply was modified 10 months, 2 weeks ago by DigTek.

Personal preference I guess. I think the page is cleaner when all the items have a one line description. Some get long winded, but in most cases that one line does help explain what the plugin does when the title is not sufficient. I was just messing with some options mainly for my own use, but here is the page if you want to see why I like it that way.

https://wpmain.elite-star-services.com/plugin-testing/

Sorry, the changes made were to this function.
I also wanted to skip a plugin, so added that bit,
but the main thing was being able to offer a Short Description.
My little hack works fine, but it was not immediately obvious
how I could add the maximum length to the shortcode,
like max_desc=140 rather than having it hard coded.

<code>
 function replace_plugin_list_tags( $plugin_data, $format, $nofollow, $target ) {

	// SKIP PLUGIN BY NAME
	if ($plugin_data['Title'] == "Plugin Name") { unset($format); }

	// CREATE SHORT DESCRIPTION (truncate at first period or 140 characters)
	$pre_desc = explode('.', $plugin_data['Description']);
	$sho_desc = $pre_desc[0];
	$pos=strpos($sho_desc, ' ', 140);
	$sho_desc = (strlen($sho_desc) > 140) ? substr($sho_desc,0,$pos).'...' : $sho_desc.'.';

	$format = strtr(
		$format,
		array(
			'{{Title}}'        => $plugin_data['Title'],
			'{{PluginURI}}'    => $plugin_data['PluginURI'],
			'{{AuthorURI}}'    => $plugin_data['AuthorURI'],
			'{{Version}}'      => $plugin_data['Version'],
			'{{Description}}'  => $plugin_data['Description'],
			'{{ShortDesc}}'    => $sho_desc,
			'{{Author}}'       => $plugin_data['Author'],
			'{{LinkedTitle}}'  => "<a href='" . $plugin_data['PluginURI'] . "' title='" . $plugin_data['Title'] . "'" . $nofollow . $target . '>' . $plugin_data['Title'] . '</a>',
			'{{LinkedAuthor}}' => "<a href='" . $plugin_data['AuthorURI'] . "' title='" . $plugin_data['Author'] . "'" . $nofollow . $target . '>' . $plugin_data['Author'] . '</a>',
			'#Title#'          => $plugin_data['Title'],
			'#PluginURI#'      => $plugin_data['PluginURI'],
			'#AuthorURI#'      => $plugin_data['AuthorURI'],
			'#Version#'        => $plugin_data['Version'],
			'#Description#'    => $plugin_data['Description'],
			'#Author#'         => $plugin_data['Author'],
			'#LinkedTitle#'    => "<a href='" . $plugin_data['PluginURI'] . "' title='" . $plugin_data['Title'] . "'" . $nofollow . $target . '>' . $plugin_data['Title'] . '</a>',
			'#LinkedAuthor#'   => "<a href='" . $plugin_data['AuthorURI'] . "' title='" . $plugin_data['Author'] . "'" . $nofollow . $target . '>' . $plugin_data['Author'] . '</a>',
			'{{'               => '<',
			'}}'               => '>',
			'{'                => '<',
			'}'                => '>',
		)
	);

	return $format;
}
</code>

• This reply was modified 2 years, 1 month ago by DigTek.

As an update to this, mootools is a legit thing, so maybe the plugin author in question did do something funny, but I have no specific reason to believe that is the case either. I run several layers of firewalls including one specifically designed for wordpress. I understand even that is often just giving false confidence because generally, if you have something someone really wants to hack, they may eventually get through.

Anyway, to the point. I went and picked up a newer version of mootools core from their repository and swapped it in to the plugin folder, which corrected the js problems.

Nice, so it was another plugin all along, just like you said.
Sorry I seemed reluctant about that, I am not surprised that is the case, but have also spent countless hours turning plugins on and off with no results in the past.

I appreciate you taking the time to work this out, I disabled the plugin, I don’t think I am using it with my current configuration on this site – it was supposed to be the logic for an animated shadowbox thing (which it is, I mean the shadowbox does work even if it comes with accidental or intentional ‘extra features’). I see that on another site where I am still using that to pop up maps and stuff, it has created the same ‘undefined’ situation, so I am going to need to find a work-around for that this weekend I suspect.

Thanks Again

Oh, the site itself has public pages, the form and such is in a private area that is unrelated content wise, but to run this stuff you can go to:
https://bigbq.com/

Object.getOwnPropertyDescriptor
does return
? getOwnPropertyDescriptor() { [native code] }

Element
? (){return(arguments[0]!==null&&this.initialize&&$type(this.initialize)==’function’)?this.initialize.apply(this,arguments):this}

Element.prototype
returns this, which drills down
{initialize: ?, set: ?, inject: ?, injectBefore: ?, injectAfter: ?,?…}

Object.getOwnPropertyNames(Element.prototype)
returns this, which also drills down
(68)?['initialize', 'set', 'inject', 'injectBefore', 'injectAfter', 'injectInside', 'injectTop', 'adopt', 'remove', 'clone', 'replaceWith', 'appendText', 'hasClass', 'addClass', 'removeClass', 'toggleClass', 'setStyle', 'setStyles', 'setOpacity', 'getStyle', 'getStyles', 'walk', 'getPrevious', 'getNext', 'getFirst', 'getLast', 'getParent', 'getChildren', 'hasChild', 'getProperty', 'removeProperty', 'getProperties', 'setProperty', 'setProperties', 'setHTML', 'setText', 'getText', 'getTag', 'empty', 'addListener', 'removeListener', 'addEvent', 'removeEvent', 'addEvents', 'removeEvents', 'fireEvent', 'cloneEvents', 'getElementById', 'getElementsByClassName', 'getElements', 'getElement', 'getElementsBySelector', 'getValue', 'getFormElements', 'toQueryString', 'scrollTo', 'getSize', 'getPosition', 'getTop', 'getLeft', 'getCoordinates', 'effect', 'effects', 'makeResizable', 'makeDraggable', 'send', 'matches', 'closest']

OK
Notepad++ does it also I see, the folder is already in my local network.

delete Object.getOwnPropertyDescriptor
does not show up at all

Object.getOwnPropertyDescriptor
shows up over 600 times, often in the includes folder js files
It also shows up in plugins, but they are mainstream plugins and disabling them did not change the issue.

Is there a more specific or alternate search I can run?

It may be worth noting that there are no other problems with the website that has been running since 2013, so while I am not disputing the fact that other websites I checked are not returning undefined, it is not ‘crashing my entire website’ either, only your newer plugin versions are affected, everything else is and has been fine.

How would I go about scanning for something like that, nothing shows up in the source.

Hmm.
Sorry.
Maybe I did something funny (like was on a different site somehow) when I got the:
{set: undefined, enumerable: true, configurable: true, get: ?}

Because now it is undefined when using either 2.1.3 or 2.1.6.
I have both backed up locally and can ftp them in as needed (or use WP Rollback).

Both here and on my site running 2.1.3 I get no errors, and this is returned:
{set: undefined, enumerable: true, configurable: true, get: ?}

That does return undefined.
I spent over an hour looking at some (recently updated) plugins, but with over 60 in use and more than a few required for the site to work, I ended up rolling back to 2.1.3, which works fine even with WP core fully up to date. I cannot easily provide a link, the form is private and deals with sensitive data. I am still fine trying to help, the site is somewhat modified, with many pages driven by custom php code, but that form itself only uses the Dynamic Text Extension plugin and CF7/Flamingo, which are not modified.

I do get this is the console:

Uncaught TypeError: Cannot read properties of undefined (reading 'get')
    at Object.get_simplified_dom_model (scripts_es6.js:1229:24)
    at wpcf7cf_reload_dom (scripts_es6.js:72:27)
    at Object.get_nested_conditions (scripts_es6.js:1143:9)
    at ./js/scripts_es6.js.Wpcf7cfForm.updateGroups (scripts_es6.js:463:38)
    at new Wpcf7cfForm (scripts_es6.js:228:10)
    at HTMLFormElement.<anonymous> (scripts_es6.js:1532:24)
    at Function.each (jquery.min.js:2:3003)
    at s.fn.init.each (jquery.min.js:2:1481)
    at ./js/scripts_es6.js (scripts_es6.js:1531:23)
    at __webpack_require__ (bootstrap:19:1)

If I revert to a backup running 2.1.3 and clear my cache everything works fine, once I go back to 2.1.6 the problem returns. Specifically, the form loads, and everything outside of groups works, the form will submit, send the email and log to flamingo. I have not changed anything on the site other than running updates for months.

Don’t take this wrong, it is just an observation about troubleshooting guide’s that suggest sites with 50+ plugins, some that are required for things to work properly in the first place, can just be disabled to test a plugin – my experience is that the easiest way to handle broken plugins after an upgrade is to simply restore the last working version and edit the file so it will not auto-update, which is much faster and easier. I can then check back at a later date, when usually a newer version does fix the issue. The other option is to just switch to another plugin offering the same function that is not broken, also faster and easier in most cases (though it would not be here due to the number of conditions in use).