efc
Forum Replies Created
-
Forum: Plugins
In reply to: [Custom Admin Bar] PHP errors in strict mode for custom-admin-barHi @aristath, if you turn on WP_DEBUG you should see them too. One complained about the redundant definition of the constructor, the other about the static call to a non-static function.
Today I realize that you may have written this as it is to cover your PHP 4 and 5 bases. If that is the case, then maybe we just have to live with the notifications under WP_DEBUG.
Great! Looking forward to it. Thanks.
Forum: Plugins
In reply to: [wp-Typography] Tweak to avoid debug depreciation error@dankicity, thank you thank you!
I just worked out half these on my own, thank you for sharing these with everyone.
I love this plugin, but I guess it is no longer being maintained. That’s a shame.
Your patches were very helpful.
Oops, that workaround does not work because the
$wp_queryglobal has not yet been filled in.Still looking for a way to get infinite scroll to obey
orderby.I am working around this issue with an
ifstatement around theadd_actionfor now, so that infinite scrolling is not supported on pages where it misbehaves.if ( $GLOBALS['wp_query']->query['publications'] || $GLOBALS['wp_query']->query['pubtype'] ) { add_action( 'after_setup_theme', 'my_infinite_scroll_init' ); }This simply looks for the existence of these types in the query array object of wp_query, and if it finds them it skips the
add_action.There must be a better way…
An option would still be nice, but here is a good workaround.
If I have a custom taxonomy called
pubtypethat I want to see as a column on my custom post type calledpublicationI can include the following in myfunctions.phpfile:add_filter( 'manage_taxonomies_for_publication_columns', 'my_publication_columns' ); function my_publication_columns( $taxonomies ) { $taxonomies[] = 'pubtype'; return $taxonomies; }Note the filter’s name is
manage_taxonomies_for_{$post_type}_columns.Forum: Plugins
In reply to: [CMS Tree Page View] Orderby should include post_titleHuh, I guess I’d never noticed that TPV reorders the menu order if I drag items. Interesting.
Instead I’ve been frustrated that TPV uses the menu order instead of allowing itself to be sorted by ‘title’ or ‘date’.
To resolve that, I’ve added a global variable
$cms_tpv_orderbytocms_tpv_get_pages()and then change the arguments array so that"orderby" => $cms_tpv_orderby ? $cms_tpv_orderby : "menu_order",instead of just defaulting to menu_order. This way I can override the sort order by simply setting the global$cms_tpv_orderby = 'title'(for example) in my ownfunctions.phpfile.This works fine (except that I have to recreate it after each update). I was going to ask that this be moved into the core plugin itself, but now I realize this might make a big mess of the reordering that TPV does based on menu_order. Since I never tried that, I never noticed.
Hm. Not sure what is right now. I sure do find my long lists of page much easier to navigate in title order, but that would make reordering a bit nonsensical. Maybe if a few options were built in to TPV, it could turn off the reordering when other orderby options were in force.
I think I see the problem in line 185 and 186 of
wpcf.phpwhich states…$reserved = array_merge( array_combine( $reserved_names, $reserved_names ), array_merge( $post_types, $taxonomies ) );The problem seems to be that in the preceding few lines the
$post_typesarray has included the custom post types created by the plugin itself. So, of course, the WP_Error at line 188 will be returned.Not sure what the fix is, since there is some other stuff going on (like a
$contextvariable used to “avoid checking itself”), so I am still not sure how to resolve this. The upshot is, though, that I can’t edit any existing custom type, since it thinks they are all their own reserved words!@srdjan… I don’t know about @kcorcoran, but I am seeing this with 1.4.0.1.
I can create a new type, but whenever I try to edit it I get the message “You cannot use this slug because it is a reserved word, used by WordPress. Please choose a different slug.”
Could this be a conflict with another plugin? I have CPT-onomies also installed.
Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesOops, Pär, I didn’t catch this note till now. Thanks so much for implementing this fix! Yes, it is working just fine.
Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesI think I have the fix you need, Pär…
In your functions.php remove line 1255 (the
esc_html()line).Make line 1325:
"title": <?php echo json_encode($title) ?>,Make line 1355:
"post_title": <?php echo json_encode($title) ?>Note the elimination of a set of quotes in 1325 and 1355 since
json_encode()provides those quotes.Oh, and to keep the ‘no title’ case visible, replace line 1253 with:
$title = __('(no title)', 'cms-tree-page-view');The plugin could probably be simplified by just constructing the whole array of values in PHP and then using
json_encode()around the whole array to build the JSON. This might even fix other lurking problems. But for now, replacingesc_html()withjson_encode()this way will do the trick!Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesAh! Getting closer… you use
esc_html()because you want to sanitize the string for inclusion in the JSON block later. But then, when you bring it out of JSON in the JavaScript for display, you do not reconstitute the HTML. There must be another way…Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesJust took a moment for a deeper look.
It appears that the problem really is a few lines further along:
$title = esc_html($title);If you compare this with the
_draft_or_post_title()function in /wp-admin/includes/template.php (which is called to fill in regular title lists) you see the difference is that you escape HTML and WP does not.However, if I try to comment out your
esc_html()then CMS Tree Page View hangs with an eternal “Loading…” indicator.Since you are escaping the HTML anyway, I’m not sure how using
get_the_title()is helping plugins that ship HTML. But I also don’t know why this plugin hangs when the HTML is not escaped.Also, note, if you do find out how to allow the HTML through, as WP does, then you should probably change the
"<Untitled page>"to(no title)as used by WP so that the angle brackets don’t make the text disappear. This would also be more like the rest of WP and avoid the issue that sometimes these are not “pages” but other content types.Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesNope, 1.2.9 does not fix the problem with wp-Typography.
Here’s what it looks like with
get_the_title()http://imgur.com/Cr2B85oAnd here it is in the regular page list http://imgur.com/pGz8dnR
The point is that the HTML output is not being properly rendered anyway, so
get_the_title()is not helping other plugins anyway. If it were being rendered as HTML that would be fine, but it is being output as text.It is better to ignore the HTML than to output it as text, and it is more consistent with the rest of the WordPress dashboard, which does the same thing.
Forum: Plugins
In reply to: [CMS Tree Page View] HTML in TitlesThis is a very simple problem to fix, but a few revisions have now come and gone without any action. Is there a reason this will NOT be done? I note that other parts of the WordPress dashboard which display these titles do not use
get_the_titleand so do not suffer from this problem (see the regular title list, for example).Why must CMS Tree Page View be different?
It would be a big help if this could be fixed in the actual plugin so that I didn’t have to patch my copy after each upgrade. Thanks!