Make WordPress Core

Opened 13 years ago

Closed 12 years ago

#17276 closed enhancement (maybelater)

custom post type problems needs addressed

Reported by: squeeky's profile squeeky Owned by: squeeky's profile squeeky
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: needs-patch
Focuses: Cc:

Description

Upfront, archive-POST_TYPE.php does not always resolve correctly - But considering the whole scope of things > Custom Post Type support is lacking in general / and such would be easy enough to bring the wordpress core up to the task / INCLUDING WIDGETS

I see no impedance to updating the core as to create a sensitivity that could handle ALL aspects of custom post types, once created, as the core handles posts, pages, attachments, menus - everything is there - we just need to open it a slight bit wider...

AND TA-DA - FULLY FUNCTIONAL & INTEGRATED CUSTOM POST TYPES THE MOMENT THEY ARE CREATED . . .

IF (wp community is) open to this idea / and time enough for inclusion in 3.2 > I'll submit code as needed.

here's a small pseudo taste:

default widgets, like Categories, Tag Cloud, Calender, ETC. run check for none built_in post types - when present & compatible > widget presents new option as to which post types it is desired to be used for...

-- i've already done (dev'ed) this / easy stuff here guys / and powerful > sure beats the current run around

Attachments (3)

tax-categories-widget.php (6.4 KB) - added by squeeky 13 years ago.
example of custom post type and custom taxonomies integration ( purposal for new Categories widget )
default-widgets.php (46.6 KB) - added by squeeky 13 years ago.
modified version of wp-includes/default-widgets.php
default-widgets.diff (46.6 KB) - added by squeeky 13 years ago.

Download all attachments as: .zip

Change History (44)

#1 @dd32
13 years ago

If you've written some code.. post it.. It might be able to explain your idea a bit easier..

#2 @scribu
13 years ago

  • Keywords reporter-feedback added

This ticket is rather vague.

Please describe more precisely what limitations you are running into, preferably with steps to reproduce.

#3 @squeeky
13 years ago

  • Component changed from General to Taxonomy
  • Keywords needs-patch added; reporter-feedback removed

ok - I'll submit a code example shortly. . .

but for now - to be more precise:
currently, to work with custom post types, once registered a user needs to jump through hoop after hoop to get the custom post types to integrate properly with the public side of an install / all the way from template creation to navigation menus - where either coding is needed or extensive plugin hunting (along with trial-&-error testing)

what i am saying is:
it does not need to be like this - nor should it be like this...

specifically - ALL aspects of the default wordpress install can be set to AUTOMATICALLY handle ALL aspects of custom post types just as it currently handles built_in post-types / in the following manner

  • integrating into the core a mere test to first see if custom post types have been registered
  • then: if exist, set what features of built_in post types may logically apply to (be used for) the custom post type > is it like a Post, is it like a Page / should it be handled like a Post / should it be handled like a Page / is the taxonomy like categories / is the taxonomy like tags / and so on...
  • finally: open the features up that are for the built_in post types to also be directly used by custom post types which are set in such a way it calls for using such features > with the above tasks, each feature (widgets, templates, etc.) would "know" exactly which custom post type it can handle AND WHEN it should handle a custom post type (via request)

, , , , , , , , , , , , ,

sort of like that.

it should make more sense once i share some code tidbits - i'll submit a snippet once i've the time / should be within 24 hours (if not sooner)

, , , , , , , , , , , , ,

on a side note > why can't / or HOW CAN permalinks be automatically reset/updated/flushed (whatever) directly after a new post type has been registered ? - I played around with this but found nothing that could be coded which would dismiss the need to visit "Settings" > "Permalinks" --- an "auto-permalink-update" SHOULD be part of (the last part of) registering a custom post type.

squeeky

Last edited 13 years ago by squeeky (previous) (diff)

#4 @scribu
13 years ago

You can't automatically flush rewrite rules after registering a new post type because post types are not stored persistently somewhere (such as in the database). Therefore, there's no way for WP to ask "hey, is this post type new?" and know the answer.

As for the rest of your proposal, you must have missed the initial discussion about post types: there's no point in using custom post types if they behave just like normal posts. You can just use categories and tags and post formats to group and style posts.

Therefore, I'm afraid this ticket will be closed as wontfix. Will wait to see your patch first.

#5 @squeeky
13 years ago

  • on "automatically flush rewrite rules" :

post types do not need to be stored persistently to alleviate the need to visit "Settings" > "Permalinks" after registering a new custom post type - I did a quick test - in wp-includes/post.php within the "function register_post_type" I merely dropped (inserted) the following line :

		$wp_rewrite->flush_rules(false);

between lines 1003 and 1004 - so it now is :

		$wp_rewrite->add_permastruct($post_type, "{$args->rewrite['slug']}/%$post_type%", $args->rewrite['with_front'], $args->permalink_epmask);
		$wp_rewrite->flush_rules(false); // *inserted line
	}

i just did this / without much thought / but that single line there now makes it so that there is no need to visit "Settings" > "Permalinks" after registering a new custom post type - i'm sure some of you who know wordpress inside-out could figure out an even better way to do this - and i SUSPECT something like this for registering taxonomies might be good too (i don't know / i didn't test that yet)

, , , , , , , , , , , , ,

  • RE "Custom Post Type support is lacking in general" :

you state "there's no point in using custom post types if they behave just like normal posts" < very true - i know this, of course - BUT no matter how unique a custom post type is, chances are it will have certain aspects (and only "certain aspects") in common with built_in post types - and therefore can certainly utilize features already in place for such aspects...

I will (by tomorrow) submit a working example of alterations to the default categories widget...

where additional options for the handling of hierarchical taxonomy for custom post types ONLY kicks in IF :

  • FIRST > custom post types exist
  • AND SECOND > custom post types has taxonomy that is hierarchical

ELSE :
widget remains as current default / and option to use for "custom post type categories" will not be present

THE WIDGET will ILLUSTRATE what I am referring to - and hopefully serve as a jump off point to bring other built_in features already in place to function with aspects of custom post types > WHERE APPLICABLE

in other words, my little example SHOULD serve to illustrate functionality that is actually MUCH MUCH WIDER IN SCOPE

Last edited 13 years ago by squeeky (previous) (diff)

#6 @scribu
13 years ago

I did a quick test - in wp-includes/post.php within the "function register_post_type" I merely dropped (inserted) the following line :

$wp_rewrite->flush_rules(false);

That would mean that flush_rules() is called on every page load. flush_rules() exists because rewrite rules are cached, so that they don't have to be generated on every page load, since they can take a long time. I hope you see the contradiction.

Version 0, edited 13 years ago by scribu (next)

#7 @squeeky
13 years ago

so are you actually saying that the FUNCTION register_post_type is called on every page load ??? > AND that's how where i placed "$wp_rewrite->flush_rules" gets called on every page load...

OR are you saying somehow the area i placed that line gets called without actually calling the FUNCTION register_post_type ???

neither case makes sense to me - if you could explain what i might be missing, that might help - if not > i understand you're very busy...

I mean I figured what I did was not "right" or the best way to do it - but "called on every page load" - i'm sorry > but now i'm really lost (and so many of my years programming just flew out the window)

but if you can explain this to me, perhaps then you could also explain how while in the FUNCTION register_post_type the "$wp_rewrite->flush_rules" line would get called on every page load / BUT in the FUNCTION wp_delete_post and the FUNCTION _save_post_hook "$wp_rewrite->flush_rules" would not be called on every page load (both also in post.php) - ?

#8 @scribu
13 years ago

Yes, register_post_type() is called on every page load (multiple times, actually).

wp_delete_post() and _save_post_hook() are only called when a post is deleted or saved. Makes sense?

Just add an echo "<br> calling __FUNCTION__"; inside flush_rules() to see for yourself.

Last edited 13 years ago by scribu (previous) (diff)

#9 @squeeky
13 years ago

WOW >>> thanks for letting me know - i understand now > my problem was i was stuck in the idea of registering NEW post-types --- OF COURSE > register post type function is called for all post types

that with what you said earlier about "post types are not stored"

before i'm done you might end up teaching me everything (wink)

  • ok i'll play a little more with flush thing and then back to getting my little code example ("concept illustration") ready to submit
Last edited 13 years ago by squeeky (previous) (diff)

#10 @squeeky
13 years ago

Just for "Ha Ha's" I think I figured out the flush thing > not good, but I think I figured it out / how to auto-flush - ONLY WHEN 'NEEDED'

.....................

here's some code as a sample of the IDEA I am speaking of - It is the idea that is IMPORTANT - not the code - not the example - but the idea

it is a plugin which if better coded could replace the current Categories widget > so that IF custom hierarchy taxonomies exist it then presents the option to use them...

SO IF this were the default categories widget > it then could be used for the post Categories & in another instance used for each hierarchical taxonomy / as desired

-- please don't be distracted by my rants within the comments...
I was just going off on half baked ideas...

Last edited 13 years ago by scribu (previous) (diff)

#11 @scribu
13 years ago

Please post the plugin as an attachment, not directly in the comments.

#12 @scribu
13 years ago

Also, it doesn't make sense to mix long, unrelated comments with the code either.

#13 @squeeky
13 years ago

  • Component changed from Taxonomy to Post Types

Ahhh - thank you for the tips/instructions...

To be clear (precise), i have attached a plugin that illustrates how certain relevant aspects of custom post types and custom taxonomies could be integrated with existing default Wordpress features.

The attached plugin, or something like it (with improvements), is not actually intended to be a plugin - but rather introduces code that symbolizes how different areas of Wordpress could be updated to integrate certain aspects of custom post types and custom taxonomies, if exists, into default Wordpress operations. Also illustrated is how IF nothing new and/or relevant is registered THEN the Wordpress feature (in this case a widget) behaves as it does in default mode.

For ease of use / testing, in this particular example ("tax-categories-widget"), some naming conventions were changed (from the existing Categories widget) so as to work in parallel with the existing Categories widget - However, the code (in this example) actually is a proposal for updating the current Categories widget.

  • see attachment : tax-categories-widget.php
Last edited 13 years ago by squeeky (previous) (diff)

@squeeky
13 years ago

example of custom post type and custom taxonomies integration ( purposal for new Categories widget )

#14 @squeeky
13 years ago

to farther illustrate my point i made a new plugin that incorporates two more widgets (alterations on wordpress default widgets)

it has a slightly updated Categories widget example, and in addition i've included a Tag Cloud widget and Recent Entries widget

if interested the plugin can be found at:

http://mywebwizards.com/to-the-wordpress-core/

BE SURE TO DEACTIVATE THE FIRST TEST ("tax-categories-widget")

download install and activate: cpt-tax-widgets

http://mywebwizards.com/wp-content/uploads/2011/05/cpt-tax-widgets.zip

All the while, keep in mind these widgets only serve as an illustration

Last edited 13 years ago by squeeky (previous) (diff)

#15 @squeeky
13 years ago

Also i did mention (a few comments back) i figured out how to "flush_rules" ONLY after the first time a new post type is registered - if interested i could share that too - i believe it would be fairly efficient ...

#16 @scribu
13 years ago

Yes, please share your solution for automated flush_rules (I bet it involves storing the post types persistently, somewhere :P).

#17 @squeeky
13 years ago

LOL - no, i'm not about to ask that post types are stored persistently somewhere - but i will say this :

what really confused me is the names of the functions...

  • register_post_type
  • register_taxonomy

i'm not saying change this (fact is i don't want you to change it) - i'm only commenting on what confused me so - and that is:

the functions really 'should' have been called

  • recognize_post_type
  • recognize_taxonomy

because it seems that's what the functions are actually doing - "recognizing" (acknowledging) rather than registering

  • by definition: to register something, means to gather its info and store it persistently somewhere - by definition: to add it to a book or list

again, i am not saying this should be changed, i am only saying what confused me > a function called "register_ ..." that does not register anything - who would of thunk it.


but no > the auto-flush method i thought of does not involve storing post types persistently somewhere ;)

and maybe the method i thought of is not as efficient as i thought because of that - but i'm sure you can figure out how efficient it would/could be...

AUTO-FLUSH METHOD (IDEA)

  • first thing within register_post_type run test to see if post type is "registered" yet > if not : set flag $new_post_type to TRUE
  • then where fitting: IF( $new_post_type ) auto-flush
Last edited 13 years ago by squeeky (previous) (diff)

#18 @squeeky
13 years ago

  • on the auto-flush method:

of course, being that post types are not actually "registered" (but instead "recognized") means that the method i submitted is not extremely efficient because such needs applied all the time / every call to "register_post_type" - but given that, the method is not all that bloated. (or maybe you'll inform me otherwise - so thx in advance)

here's a quick question - i am assuming $wp_post_types is also dynamic (not persistent) - it has to be, right - i can't see how it could not be...

. . . . . . . . . . .

  • on "Custom Post Type support is lacking in general" :

keep in mind the widget(s) examples is merely a small (very tiny) part of all that could be done - and here, on this stuff, i have given much more thought, than i have to the auto-flush stuff.

Last edited 13 years ago by squeeky (previous) (diff)

#19 @squeeky
13 years ago

WOW !!! i give up on the auto-flush thingy :P

for now at least.

how/what/where ???

i got close but couldn't get anything stable / that worked smooth in different installs

oh well > that is not what this ticket's focus is really about anyway.
indirectly it is, but "focus" no...

so i'm gonna drop the auto-flush stuff for now - maybe pick it up later > where i try something like this :

  • first thing in the function register_post_type pop out of it to another function (maybe something like "function is_post_type_new") that sets the $new_post_type (bool) flag
  • then later in the function register_post_type (where such is fitting) go back to "function is_post_type_new" and grab the $new_post_type (bool) flag

i don't know > like i said, currently this is not my main focus

Last edited 13 years ago by squeeky (previous) (diff)

#20 @squeeky
13 years ago

so i'm back enhancing some more widgets when i notice this.....

RE: wp-includes/default-widgets.php

in WP_Widget_Recent_Posts

  • 'widget_recent_entries' only appears in 4 lines...

line 513 :

		$widget_ops = array('classname' => 'widget_recent_entries', ...

line 515 :

		$this->alt_option_name = 'widget_recent_entries';

and line 568, line 569 :

		if ( isset($alloptions['widget_recent_entries']) )
			delete_option('widget_recent_entries');
  • and 'widget_recent_posts' only appears in 3 lines...

line 523 :

		$cache = wp_cache_get('widget_recent_posts', 'widget');

line 558 :

		wp_cache_set('widget_recent_posts', $cache, 'widget');

line 575 :

		wp_cache_delete('widget_recent_posts', 'widget');

this is in direct contrast to how it is

in WP_Widget_Recent_Comments

  • where 'widget_recent_comments' appears in the following 7 lines...

line 599 :

		$widget_ops = array('classname' => 'widget_recent_comments', ...

line 601 :

		$this->alt_option_name = 'widget_recent_comments';

line 620 :

		wp_cache_delete('widget_recent_comments', 'widget');

line 626 :

		$cache = wp_cache_get('widget_recent_comments', 'widget');

line 659 :

		wp_cache_set('widget_recent_comments', $cache, 'widget');

line 669, and line 670 :

		if ( isset($alloptions['widget_recent_comments']) )
			delete_option('widget_recent_comments');

Just wondered if it SHOULD be that way, does not matter, or if it is a slip up

Last edited 13 years ago by squeeky (previous) (diff)

#21 @scribu
13 years ago

Posts and comments are not equivalent, so I don't see why they should be the same. If it is a slip-up and it causes a bug, somebody will run into it soon enough and report it.

If we were to extend the default widgets to support custom post types, we would also have to introduce a new flag to register_post_type(), something like 'show_in_widgets'.

#22 @squeeky
13 years ago

hmmm --- did you see my examples ? did you test my examples ?

the latest examples ? > in cpt-tax-widgets.php

NO new flag in register_post_type() is needed / at least not in my examples...

  • each widget simply runs a SIMPLE test to see if, depending on widget's function, any custom post types OR custom taxonomies are registered
  • if custom post types OR custom taxonomies are registered, an OPTION is provided to use the widget for such (where widget's current default functionality is also the DEFAULT OPTION)
  • if NO custom post types OR custom taxonomies are registered, widget acts exactly as it does in default mode / as they do now

no flag needed in register_post_type() - this added functionality is provided with only a few lines of code AND NEVER gets in the way of widget's default operations


Custom Post Types and Taxonomy Widgets : cpt-tax-widgets

http://mywebwizards.com/wp-content/uploads/2011/05/cpt-tax-widgets.zip

you should give it a spin > i've changed the naming conventions so it does not interfere with the default widgets.


I'm not saying such would not be better to introduced a new flag for widgets to register_post_type(), something like 'show_in_widgets' / that's up to you - i'm just saying my examples fully illustrate how you do NOT HAVE TO introduce a new flag like that...

I actually think for some things i have in mind perhaps a new argument/flag might be the way to go / but not necessarily for widgets

but for widget enhancements, i think the most involved would be Archives and Calendar - i believe the functions they call would need modifications to optionally handle custom post types

Last edited 13 years ago by squeeky (previous) (diff)

#23 @scribu
13 years ago

Let me try that again: the 'show_in_widget' flag would define if a post type would show up as an option in the widget form.

Though I guess you could use the 'public' flag for that purpose.

#24 @squeeky
13 years ago

yeah - i think what you are saying about another flag for register_post_type / 'show_in_widgets' / for that functionality i was merely using 'public' => true

BUT now that i think about it, maybe i should be even more focused, and instead use 'publicly_queryable' => true

here's my thinking > ??? how and why ??? anyone would want a post type to be 'publicly_queryable' => true, BUT not want it in widgets I would have no idea

BUT > i don't need to have an idea why someone would want that --- BECAUSE IF they don't want to use the widget (as in my examples) then they don't have to use the widget for their post type(s) - they can leave the widget in its default settings - the option is their's


but boy oh boy - you got me wondering > i now think the thing to do is use 'publicly_queryable' instead of 'public' (like i did) - hmmm - looks like i gotta make version 0.4 ;)

Last edited 13 years ago by squeeky (previous) (diff)

#25 @scribu
13 years ago

Yes, for the widgets you modified, 'publicly_queryable' would make more sense.

#26 @squeeky
13 years ago

i can't get Archives and Calendar to work smoothly without modifying the functions they call...

but i got some weird neat ideas i'm playing with for Recent Comments - so maybe i'll see how far i get with that fun before i make version 0.4 where i use 'publicly_queryable' instead of 'public'

#27 @squeeky
13 years ago

it seems that the function get_post_types() can not handle 'supports' / or maybe i am doing it wrong...

			$args = array(
				'capability_type' => 'post',
				'publicly_queryable' => true,
				'show_in_nav_menus' => true,
				'supports' => array('title','editor'),
			);

			$post_type_list = (array) $post_type_list;

			foreach( get_post_types( $args ) as $posttype ) 
				$post_type_list[] = $posttype;

so i opted to do this instead

			$args = array(
				'capability_type' => 'post',
				'publicly_queryable' => true,
				'show_in_nav_menus' => true,
			);

			$post_type_list = (array) $post_type_list;

			foreach( get_post_types( $args ) as $posttype ) 
				if ( post_type_supports($posttype,'title') && post_type_supports($posttype,'editor') )
					$post_type_list[] = $posttype;


i also made a few fixes to my Tag Cloud example - when i decided to look really close at function _get_current_taxonomy($instance) - wp-includes/default-widgets.php LINE 1040 to 1045 :

	function _get_current_taxonomy($instance) {
		if ( !empty($instance['taxonomy']) && taxonomy_exists($instance['taxonomy']) )
			return $instance['taxonomy'];

		return 'post_tag';
	}

it seems somebody somewhere knew i was going to come in and start doing what i'm doing - LOL

that (what i am doing / enhancing these widgets) seems to be the only reason for...

		... ... ... && taxonomy_exists($instance['taxonomy'])

because the only thing the widget currently is used for is post tags and post categories / so if the widget was not waiting for me > then the question is > who would deactivate post categories --- hmmm / LOL

#28 @squeeky
13 years ago

ok - version 0.4 done

  • i fixed (reverted parts of) the Tag Cloud widget: so it properly selects default if it had been set to a custom tax that no longer exists
  • cleaned up some code to better adhere to the "wordpress way"
  • added the Pages widget
  • post type checks now use 'publicly_queryable' instead of 'public'

I didn't hit the Recent Comments widget like i wanted to - the kind of tweak i had in mind pulls it away from the current default settings - that is, once tweaked the way i had in mind, the Recent Comments widget would be forever enhanced and add features/settings/options which would always be there, regardless of whether costom port types were registered

also the Recent Comments tweaks i was thinking of doing require the same kind of thing the Archives and Calendar widgets require > modification of the functions they call (i can't provide the features by only altering the widget's code)


See the update - version 0.4

Custom Post Types and Taxonomy Widgets : cpt-tax-widgets

http://mywebwizards.com/wp-content/uploads/2011/05/cpt-tax-widgets.zip


this is pretty much as far as i can go without jumping beyond the widgets...

since currently my modifications seem pretty straight-forward, and stable (and do not interfere with defaults, i am going to integrate all modifications into wp-includes/default-widgets.php (and revert many of the naming conventions to current defaults) - and also submit that (the modified default-widgets.php) for review / so you can see what my modifications are like in their intended context - i'll be doing a little more "code cleaning" while i do the integration - if you can see any issues yourself before or while i am doing this please let me know

next up will be the Archives and Calendar widgets

then on to other things (like getting functions the_category() and the_tags() to work with custom tax with no extra coding needed by end-uses or theme developers)

squeeky

#29 @scribu
13 years ago

then on to other things (like getting functions the_category() and the_tags() to work with custom tax with no extra coding needed by end-uses or theme developers)

You'd be wasting your time. There already is a template tag that handles this nicely - the_terms() - and that's not going to change.

#30 @squeeky
13 years ago

yes, the_terms(), that's nice > and maybe i won't do anything then --- BUT as you can see with my widget examples, i think it's much nicer that wordpress "AUTOMATICALLY" engages the handling of the custom pt/tax > rather than the "seek/find/code" method currently needed to handle custom pt/tax - i'm not saying that someone can't "seek/find/code" to get EXACTLY what they want (how they want it), but instead i'm merely saying it's nicer if they don't have to...

i mean if custom post types and taxies are using default theme templates - it nice the post types can display that way, but then things like the_category() are broken

so i'll look into it > maybe the_category() and/or the_tags() can "jump to" the_terms() when such is fitting and makes sense - so extra "seek/find/code" is not needed

however, that's later (when i look into that) anyway - first i'm gonna get down to the Archives and Calendar widgets

Last edited 13 years ago by squeeky (previous) (diff)

#31 @scribu
13 years ago

maybe the_category() and/or the_tags() can "jump to" the_terms() when such is fitting and makes sense to so

No, that would create a lot of confusion. What if I have both a category, a tag and a custom term attached to the same post and want to display them all at once?

Automation is not always a good thing.

#32 @squeeky
13 years ago

like i said, i'm not there yet - and still am as ignorant as i was with the "auto-flush" idea...

BUT > hmmm -- good question...

i have yet to see an "out of box" theme incorporate all three > a category, a tag and a custom term - and i would imagine such would not be done by the average user - but instead would be done by a more advanced user > where as i said someone could still "seek/find/code" to get EXACTLY what they want (how they want it)

let me say i am looking for "out of the box" functionality < that does not interfere with the current defaults

but you are right - this would be trickier ...

AGAIN - i am not on this stuff right now - and i am avoiding changing the current defaults as much as i can --- BUT this might be a case where default functionality might call for a change

specifically :::::::::: MAYBE...

only use optionally added enhancement the_category() for cat-like tax / tag-like for the_tags() -- and only for for custom pt --- hmmm (i wonder..)

but more importantly - for the_category() and the_tags() > perhaps an additional parameter to close enhanced custom term handling

the above logic is this

  • if someone's skills are advanced enough to head in and add the_terms() to templates / then they're skills are advanced enough to add/set a parameter in the_category() and/or the_tags()

maybe something like :

function the_tags( $before = null, $sep = ', ', $after = '', $enhance = true )
  • THEN at least the people who don't have the skills to do this kind of stuff can still enjoy such features

finally > please again, understand i'll need to look into this first > else i'll toss out ideas like "auto-flush" in cookies ;)

Last edited 13 years ago by squeeky (previous) (diff)

#33 @squeeky
13 years ago

OH YEAH > i did think about joking with you - telling you i am updating the Text widget to handle custom post types - lol - i thought that would be a good joke...

#34 follow-up: @squeeky
13 years ago

so that you can review my work (thus far) in the enviroment it's intended for, i've attached wp-includes/default-widgets.php with the following modified widgets

  • Pages
  • Categories
  • Recent Posts
  • Tag Cloud

i've included in the modified widgets' intro comments the line "updated for 3.1.3" so each modified widget is easy to find.

i think the code, as is, would be solid enough to roll out (release), but you might find things that could be refined or brought more in the direction of the "wordpress way"

what i did not do, which i think should be done, is change the default text - for example:

  • i did not change the name of "Recent Posts" and i think naming it "Recent Entries" might be better
  • i think the same change for the "Recent Posts" description might be good, so that it would read "The most recent entries on your site"
  • more importantly, i think the description for "Pages" should probably be changed from "Your site's WordPress Pages" to something like "Display your site's pages in a list"

so some minor things like that could be updated - but now, at least, you can see my modifications in the context they are intended for....

Last edited 13 years ago by squeeky (previous) (diff)

#35 in reply to: ↑ 34 @sivel
13 years ago

Replying to squeeky:

so that you can review my work (thus far) in the enviroment it's intended for, i've attached wp-includes/default-widgets.php with the following modified widgets

It is preferred that you attach an SVN diff of the changes you have made instead of the whole file. It makes it much easier to see what has been changed in that file, since trac will create a syntax highlighted view of the changes. This will also make reviewing your work much easier and more likely to get things moving.

@squeeky
13 years ago

modified version of wp-includes/default-widgets.php

#36 @squeeky
13 years ago

the attachment default-widgets.diff could be deleted - it is merely a failed test


  • my background is C++ / i don't know this SVN stuff / you can delete this message and my attachment named "default-widgets.diff"

i need to get back to work - i'll learn this svn stuff later when i have the time - if you have a link that directly explains how to do the svn diff you asked for, that would help - but too much reading/text will not be good for me

Last edited 13 years ago by squeeky (previous) (diff)

#37 @scribu
13 years ago

Straightforward tutorials are right on the trac homepage:

http://core.trac.wordpress.org/#HowtoSubmitPatches

#38 @squeeky
13 years ago

yeah - i saw that - i was hoping for something more direct...

i'm using a WAMP localhost and i have A TON of projects i'm currently working on - i'll need to finish them up before i install subversion - as i fear installing subversion might interfere with my localhost install - would you know if my fears are founded ?

i did find instructions to integrate subversion with my localhost - hmmm...

sidenote: http://wordpress.org/download/svn/ has a link to an outdated page for subversion ( http://subversion.tigris.org/ ) - the new home of subversion is http://subversion.apache.org/ - i imagine throughout wordpress.org are pages that refer to subversion the old URL and could use updated links (eventually) - and i would not know where all these pages would be and don't really have the time to hunt for them - i know this is not the place to mention this, but i figure someone here might have a betty idea what pages might benefit being updated

#39 @squeeky
13 years ago

ok - i evaluated the personal work i must do and think i could probably get enough done to start playing with subversion before next weekend - once installed i'll submit a proper svn diff

then move on to the widgets Archives and Calender - where i believe i'll need to tweak the functions they call to get them to intuitively handle custom post types - i don't know yet but i might even need to wp_rewrite (i hope not)

@ scribu > concerning "What if I have both a category, a tag and a custom term attached to the same post and want to display them all at once?":

i did not look into it yet, meaning i am still only thinking about it - currently, i am thinking maybe an update to the functions something like this

function the_tags( $before = null, $sep = ', ', $after = '', $enhance = true )

default value for $enhance is true (so those not skilled at coding can enjoy the benefits) - and displays builtin tags and custom tax that are tag-like...

  • when $enhance == false : function the_tags acts exactly as it does now
  • when $enhance == true : auto-handle custom tax (that is fitting for "tags")
  • $enhance ALSO can accept an array used to determine formatting / just like the current parameters for the_tags > $before = null, $sep = ', ', $after =

so a coder could do something like the following:

<?php the_tags( 'Common Tags: ', ', ', '<br />', array( 'Custom Tags: ', ', ', '<br />' ) ); ?>

also eventually i'll be hitting auto-flush idea again > where i am now inspired by how widgets use $instance AND ALSO wonder how terrible it would be to (YES > YOU GUESSED IT) store ONLY non-builtin post types/tax

SO i guess above i am only saying what Arnold Schwarzenegger is famous for saying, "I'll be back"

#40 @squeeky
13 years ago

in about a week i'll the svn diff up for default-widgets / and hopetully some more stuff too...

#41 @scribu
12 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Regarding the tag cloud widget: #20238

Closing this ticket as it tries to do too much. Please open new tickets for individual issues.

Note: See TracTickets for help on using tickets.