NelsNose
Forum Replies Created
-
Forum: Plugins
In reply to: [WolfNet IDX for WordPress] Can't insert shortcodesThe conflict seems to be with Advanced Custom Fields. If I temporarily disable that plugin, I can insert the shortcode. Re-enabling Advanced Custom Fields does not prevent the shortcodes form working, but it prevents the WolfNet shortcode from being inserted.
I had the same problem on this Mac in Chrome 24.0.1312.56, Firefox 18.0.1, and Safari 5.1.7
We are using WordPress 3.5.1 with the following plugins:
WolfNet IDX for WordPress 1.1.3
Advanced Custom Fields 3.5.8.1
Category Custom Fields 1.0
Contact Form 7 3.3.3
Executable PHP widget 2.1
MCE Table Buttons 2.0
Post Types Order 1.5.7
Ultimate Coming Soon Page 1.6.1
Widget Logic 0.56
WordPress SEO 1.3.4.4Forum: Plugins
In reply to: [WolfNet IDX for WordPress] Can't insert shortcodesI should also mention I’ve tried on Mac with Firefox, Chrome, and Safari and get the same result in each.
When I review the console in FF, there appears to be an error in the js that calls the modal window “Use of attributes’ specified attribute is deprecated. It always returns true.”
Forum: Plugins
In reply to: [Simple Ads Manager] Undefined offsetPlease see related issue/post at http://ww.wp.xz.cn/support/topic/update-to-wordpress-1?replies=2#post-3635393 for a possible solution
Forum: Plugins
In reply to: [Simple Ads Manager] Update to wordpressI’m trying to figure this out, too.
I’ve changed that line from:
$version['spec'] = $subver[1];
to
$version['spec'] = isset($subver[1]) ? $subver[1] : NULL;Still testing, not guaranteed to work.
My process:
Here is the function in admin.class.php that includes line 129:public function getWpVersion() { global $wp_version; $version = array(); $ver = explode('.', $wp_version); $version['major'] = $ver[0]; $vc = count($ver); if($vc == 2) { $subver = explode('-', $ver[1]); $version['minor'] = $subver[0]; $version['spec'] = $subver[1]; $version['str'] = $version['major'].'.'.$version['minor'].((!empty($version['spec'])) ? ' ('.$version['spec'].')' : ''); } else { $version['minor'] = $ver[1]; $version['build'] = $ver[2]; $version['str'] = $wp_version; } return $version; }What I notice is that $wp_version is “3.5” in the latest WP.
$ver is an array of the version parts (as separated by ‘.’), e.g. array(3, 5).$vc therefor equals 2.
$subver is trying to create an array of the “5” part of “3.5”, splitting at “-” which doesn’t exist, so we have $subver = array(5) and $subver[1] doesn’t exist (illegal offset).
I’m not sure where this is being called, but it’s safe to assume that $version (the returned variable) needs to be an array, so we can’t just assign $version the value of $wp_version.
We can do a shorthand conditional statement instead, assigning $version[‘spec’] the value NULL if $subver[1] is not set.
Forum: Plugins
In reply to: [WP eCommerce] [Plugin: WP e-Commerce] br tag in checkout input fieldsIs the site somewhere I could take a look? Those are the only files that I’m aware of that would be affecting this.
Did you happen to try clearing your browser cache or looking in a different browser?
Forum: Plugins
In reply to: [WP eCommerce] [Plugin: WP e-Commerce] br tag in checkout input fields@ lbeetles Have you copied the template files to your theme directory as is suggested? If so, the files in your theme directory are the ones you will want to update.
Forum: Plugins
In reply to: [Search Everything] [Plugin: Search Everything] Internal post link in adminForum: Plugins
In reply to: [Search Everything] [Plugin: Search Everything] Internal post link in adminI had the same issue. My work-around has a terrible core hack.
See : [Plugin: Search Everything] Breaks admin search function for internal linking
I was able to get search/SE working for internal links on the admin page/link dialog popup.
The issue is that
$wp_query->query_vars['s']is not set by that form, it uses$_POST['search']instead.In search-everything.php, everywhere there is a
if (!empty($wp_query->query_vars['s'])), I addedif($_POST['search']) {$wp_query->query_vars['s'] = $_POST['search']; }on the line before.
The only exception to the method is the conditional statement at 153, which is a shorthand method.Then, and though it pains me, I hacked the core /includes/class-wp-editor.php. On line 695, I changed the
suppress_filtersvalue to ‘FALSE’.I know this probably isn’t ideal, but I really needed to get this working for a client. The obvious drawback is that a WP update will likely break this again.
I can confirm this is happening as well.
Forum: Plugins
In reply to: [Plugin: Custom Post Type UI] 404 error – permalink not workDoes that flush the rewrite rules on every page view? Sounds like a performance hit.
Also, there is a new version (0.6.2) since my suggested fix on 0.6.0. Which version are you using?
Forum: Plugins
In reply to: [Plugin: Custom Post Type UI] 404 error – permalink not workWe were having a similar issue with a production site, and thought it was NextGen Gallery causing the problem (since that is where we most noticed the issue).
Permalinks would break every time while:
Editing a Post or Page
Viewing a Post or Page in Admin mode
Viewing (or changing) any settings for NextGen Gallery
Viewing (or changing) any settings for HeadSpace2 (must activate ajax).Turned off all plugins, then turned on NextGen Gallery and Custom Post Type UI, testing “known break” actions between each. Custom Post Type UI caused the issue to start again.
I compared the previous versions (back through 0.4.1) and found that
flush_rewrite_rules();had been removed at 139 (v.0.5.2). Adding that back in prevented permalinks from breaking.Turned the remaining plugins back on and re-tested, fix still seemed good. Haven’t put it on the live site, awaiting input.
Sorry I can’t provide a patch at the moment.