{5} Assigned, Active Tickets by Owner (Full Description) (105 matches)

Tell the user that the default category is for either posts or links rather than just "Default".

I have created the patch using "if" then modified it to use "switch", use the better one.

Also, it will be helpful to add note about change default categories.

I tweaked the livejournal importer around to get it to read in Xanga archives. Seems to work fine for the files I have access to. Only thing is that since there are no titles in the files I have, I used the date and time for the wordpress titles. Xanga has added in titles since the archive files I have so I have no way to test that part of it out. Other than that, it works great for the 3 people I've had try it out so far.

When your blog is iso-8859-1 and your RSS widget takes information from an UTF-8 blog, the characters in your page can become garbled. The reverse is also true (your blog is UTF-8 and the RSS'd blog is ISO-8859-1). Here's my proposal for wp-includes/rss.php (around line 62):

		$this->parser = $parser;

#MODIFICATIONS BEGIN
switch( @strtoupper(get_option('blog_charset')) )
{
	case 'UTF-8':
		xml_parser_set_option( $this->parser, XML_OPTION_TARGET_ENCODING, 'UTF-8' );
		break;
	case 'ISO-8859-1':
		xml_parser_set_option( $this->parser, XML_OPTION_TARGET_ENCODING, 'ISO-8859-1' );
		break;
}
#MODIFICATIONS END
		# pass in parser, and a reference to this object
		# setup handlers
		#
		xml_set_object( $this->parser, $this );
		xml_set_element_handler($this->parser,

This would handle only iso-8859-1 to utf-8 and vice-versa, but most western blogs use one of these two encodings. Handling a percentage of the cases is better than none at all, I think. :)

It's easier to just show you the current code (as of [6772]):

    <td><?php if ( current_user_can('edit_post', $comment->comment_post_ID) ) {
	echo "<a href='comment.php?action=editcomment&amp;c=$comment->comment_ID' class='edit'>" .  __('Edit') . "</a>"; } ?></td>
    <td><?php if ( current_user_can('edit_post', $comment->comment_post_ID) ) {
		$url = clean_url( wp_nonce_url( "comment.php?action=deletecomment&p=$comment->comment_post_ID&c=$comment->comment_ID", "delete-comment_$comment->comment_ID" ) );
		echo "<a href='$url' class='delete:the-comment-list:comment-$comment->comment_ID delete'>" . __('Delete') . "</a> ";
		} ?></td>

I don't see any point in repeatedly checking if the user has sufficient permissions on the same page. Let's simplify it a bit and check for user permissions once.

Filing this as an enhancement because it could do with some discussion and insight from wiser and more experienced heads before being labelled "defect". :-)

I noticed while helping some users import their blogs that importers of HTML content (such as the RSS importer) don't tidy up superfluous newlines in the import format, which results in unnecessary <br/> elements after wpautop() filtering for display. They turn up in the editor too, which reinforces the problem.

I've adapted one of the filter functions to strip superfluous newlines, and changed my RSS importer to use it. The results have been warmly welcomed by users, who no longer have to clean up their imported blog content. ;-)

strip_newlines() should probably go into wp-includes/formatting.php, if there isn't already a function that already serves this purpose. I couldn't find one, so I adapted this.

Given that similar HTML block/inline-savvy string-replacement code exists in other formatting functions, perhaps there's an opportunity for some refactoring here? I feel kind of silly proposing a function that is almost entirely duplicated from other code in the core.

I've used it immediately before the "Clean up content" section in wp-admin/import/rss.php's get_posts(), and in an Advogato importer that I've written (which also uses HTML as the content format).

function strip_newlines($text) {
	// Respectfully strip unnecessary newlines
	$textarr = preg_split("/(<[^>]+>)/Us", $text, -1, PREG_SPLIT_DELIM_CAPTURE);
	$stop = count($textarr); $skip = false; $output = ''; // loop stuff
	for ($ci = 0; $ci < $stop; $ci++) {
		$curl = $textarr[$ci];
		if (! $skip && isset($curl{0}) && '<' != $curl{0}) { // If it's not a tag
			$curl = preg_replace('/[\n\r]+/', ' ', $curl);
		} elseif (strpos($curl, '<code') !== false || strpos($curl, '<pre') !== false || strpos($curl, '<kbd') !== false || strpos($curl, '<style') !== false || strpos($curl, '<script') !== false) {
			$next = false;
		} else {
			$next = true;
		}
		$output .= $curl;
	}
	return $output;
}

Thoughts?

I myself had a hard time figuring out that I was able to reorder my widgets by clicking and dragging them—it shouldn't be so hard to find out.

In the new Plugin Installer, you can upload a zip file to install from, but you cannot enter a remote url to install the zip from. Seems like this would be hand-in-hand for the functionality desired from a Auto-Installer like this.

I'm looking at writing a logging infrastructure so that logIO() and debug_fwrite() can be consolidated into a single plugin replacable function (giving potential expansion into MySQL or syslog logging). I hope to follow this up with calls to the same function so administrative access can leave an audit trail.

An abbreviated year followed by punctuation or markup doesn't texturize properly.

e.g. (Bruce Sterling, '97) is texturized as (Bruce Sterling, &#8216;97) when the apostrophe should be texturized as &#8217;

e.g. <li>Casino Royale '06</li> is texturized as <li>Casino Royale, &#8216;06</li> when the apostrophe should be texturized as &#8217;

If you have more than one nonced admin form one page, you'll have multiple hidden inputs with an ID of "_wpnonce" which renders the XHTML invalid.

autosave.js appears to rely on that ID ... one solution would be to increment the ID each time it is used: _wpnonce, _wpnonce2, _wpnonce3.

It's a hidden form field, so the only real use for the ID is in jQuery, and it doesn't appear we're using it other than in autosave (and there's only one _wpnonce ID on the write screen).

I created a new admin script used to import Blosxom blog entries (and comments) to Wordpress. This script is just like import-mt.php, import-rss.php, etc.

There was some discussion about comment meta (I think in a wp-meetup), but I can't find a ticket, so here it is.

There should be a commentmeta table that stores metadata associated with specific comments. This allows plugins to store data associated with specific comments, instead of trying to shoehorn it into postmeta somehow. Some possible uses:

• Geo data
• Additional fields (like a quiz, or the commenter's age, etc)
• A link to the commenter's CoComment? feed
• The name of the commenter's site
• Comment subscription status (my plugin alters the comment table... something I wish could have been avoided)
• Antispam plugin data related to the comment

Here is a quick mockup (non-functional HTML) of my category improvement idea:

http://img167.imageshack.us/img167/3561/picture3pz6.png

"Assigned categories" should be populated via AJAX, removed via AJAX. Category tree can and "Assigned categories" can work with each other... unchecking removes from assigned categories, or clicking the [x] removes the check. Ideally, you'd be able to hide either the flickr-like tag interface or the traditional category tree, so you could just use one or the other. Tags + Categories... best of both worlds.

Thoughts?

The nice permalink URIs for posts or categories are case-insensitive, but the page URIs are not.

e.g. http://matt.wordpress.com/about/ cannot be reached via http://matt.wordpress.com/About/

This results in 404s being returned when a user incorrectly gets the case of the URI wrong. This is particularly a problem for weblogs that have migrated old pages to WordPress, and have external pages pointing to them with varying case applied to the URIs.

Scenario

Title-less blog posts are common in linklogs (aka asides). Currently WordPress does not generate titles for these types of posts, which has two implications:

• nonexistent titles appear in feeds, which break some aggregators that rely on the existence of a title to link back to the post
• post_names (aka slugs) get generated based on the post ID, creating human-unreadable permalinks, e.g. http://example.org/2007/02/4201/

Prior Art

• Blogger uses the first 32ish characters of the post for the post_title and post_name, without breaking a word in half
• Jason Kottke generates a post_title based on the first 70ish characters of his post, without breaking words, adding ellipsis to titles that were based on truncated content. Note: the generated title is only visible in his feed.
• I'm not sure what MT does

Proposal

I propose that WordPress generate a title for title-less posts, at the moment the post is published (similar to how a post_name is generated) based on the first 100 characters of the post_content (excepting html tags).

This generated title would then be the basis for the post_name. In the event that 100 characters falls in the middle of a word, that word would not be included in the generated title. For all titles generated from content greater than 100 characters in length, 3 periods (...) will be added to the end of the title (aka an ellipsis) which wptexturize will later translate into a ellipsis entity.

Implementation

I've implemented this as a function called generate_title_from_content(), see attached patch.

WordPress 2.3 includes a new canonical redirect feature. It is designed to deal with such problems as Google seeing yoursite.com and www.yoursite.com as two different entities.

Some hosting providers offer a similar redirect feature. With DreamHost, for example, you can configure your domain so that the web server redirects any request for www.yoursite.com to yoursite.com (i.e., it removes the www prefix).

When both of these features are enabled at the same time, they conflict with each other. You will experience HTTP errors such as:

Too many HTTP redirects

or:

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

To fix this problem, you must go to the WordPress admin page and switch to the Options > General section. For the WordPress address and Blog address entries, remove the www prefix from both URLs.

The canonical redirect feature should be changed so that this problem doesn't occur. For example, canonical redirection could be disabled by default, or perhaps there is some way for WordPress to detect the www prefix removal by the web server and then automatically remove www from the URL entries in the WordPress settings. At the very least, there should be a documentation note on this problem and how to fix it.

This ticket is related to #5089 and #5017.

Patch adds a WordPress logo to wp_die().

A 3rd parameter has been added to allow turning the logo off. Not that i'm sure what need there is for it(I was originally going to opt-in for the logo).

I'm leaving this marked as a defect as i'd expect a logo to be shown on the error page myself, it tells me who the error is coming from.

On one site we've had a number of comments being automatically classed as spam where the user has included the character ' (& also possibly "). These are being converted into &#039; (when I've used print_r to put create the body text for wp_mail they're actually \&#039;) and then are being flagged as spam by wp_blacklist_check.

If I amend line 415 of wp-includes/comment.php to check for character 39 as well then the same comment is added into the comment list for approval.

No extra spam filters/plugins have been included on the site, it's just using the default processing supplied by WP 2.5.1. Nothing has been added to the comment blacklist setting in Settings->Discussion

The site is running on a shared Unix server & the hosting company have switched off phpInfo(), so unfortunately I can't supply the settings there.

By inserting the included code on line 416 in template-functions-post.php, we can increase the styling capability of the wp_list_pages() template tag. This adds a class for parent li's which makes more advanced navigation styles possible.

if ( $page_id == $queried_obj->post_parent )

$css_class .= ' parent_page_item';

I would love it if someone can make help to expand this so that it can recognize more than one level of sub pages.

Not sure if this should slide into 2.3 or if it can wait for 2.4. Change as need be.

wpautop() has issues with closing </p>'s when it comes to HTML.

For example:

Foo<div>Bar</div>

Results in:

<p>Foo
<div>Bar</div>

Current trunk.

When editing a text widget, there's a link on the bottom left named "Change" and a link in the upper right named "Cancel". These links do basically the same thing as far as I can tell. Either way, changes you've made to the content of the widget is altered. When you "Save Changes", your widget will be altered.

Seems like a usability issue to me.

I've just updated backPress to include both WP_Scripts and WP_Styles both of which inherit from WP_Dependencies (a generic "this thing depends on that thing" class).

Attached is a patch that converts WP over to the backPress classes.

Scripts work just fine; the API has not changed, and the class methods themselves are all backward compatible. Styles are there, but nothing uses them right now. WP should probably have a wp_default_styles() function (analogous to the patch's wp_default_scripts() function).

I don't know if we'll use the dependency functionality much for stylesheets (like we do for scripts), or if we just want to use it as a stylesheet queue/loader.

The new files have names that adhere to the backPress naming "standard" (a made up, arbitrary standard). We can name them whatever we like.

svn stat

A      wp-includes/class.wp-dependencies.php
A      wp-includes/class.wp-scripts.php
A      wp-includes/class.wp-styles.php
A      wp-includes/functions.wp-scripts.php
A      wp-includes/functions.wp-styles.php

M      wp-includes/default-filters.php
M      wp-includes/script-loader.php
M      wp-admin/admin-header.php

2.5 introduced inline documentation in the administration areas - many options now have short descriptions.

However, some of these could be made superfluous if only the options they were documenting were properly explained in the first place.

For e.g., in the post edit page, the option for allowing pingbacks and trackbacks reads "Allow pings", and is followed by and explanation that reads "pings are trackbacks and pingbacks". Isn't it easier to just say "Allow trackbacks and pingbacks", and this way be more consistent with other mentions of these concepts elsewhere in the admin?

A more obvious example is in the link edit page. Options for setting the target value are just the meaningless "_blank", "_top" and "none", and these are followed by an explanation that reads "Essentially this means if you choose _blank your link will open in a new window" (i.e., "We confused you with too many options you don't care about, but this is how to get what you really want here"). I would suggest simply explaining what these options do - "_blank (new window/tab)", "_top (breaks out of frames), "none (same window)".

I suppose there are more examples, these are just a few that stood out.

I had wordpress 2.2.2 hosted on FastHosts? and wasn't getting any email notifications, everything was landing in dead.letter. After some investigation I found it was because the phpmailer->Sender wasn't being set. Fasthosts check the sender email address to make sure it's a valid email address for an account in your domain as part of their spam filtering rules.

If you add the line

$phpmailer->Sender = "wordpress@" . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME']));

to pluggable.php on wp-includes before the line

$phpmailer->FromName = "WordPress";

I found this fixed the issue.

Reference: http://wordpress.org/support/topic/53061

Wordpress relies on the PHP date() and time() functions for most date/time processing. This limits wordpress's ability to handle dates outside the valid range of a timestamp [typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows).]

Wordpress should be able to handle any date, including dates outside this range. This is needed for entering historical data.

Separate variables for Year, day of year, and time of day will handle any date. (other choices will work equally well)

Using the adodb_date_library http://wordpress.org/support/topic/27367#post-194153 as a workaround has worked for some, but I'm still having trouble with dates before 1900.

e.g. http://danielcady.com/letters/ A post dated Sept 2, 1812 is displayed as September 9th, 1948 (The permalink doesn't work either)

MT supports dates outside the range 1901-2038

Dates in Wordpress should not be limited to the range of the intrinsic php functions based on a 32bit value. (Note that MySQL does not store the time and date in a 32bit signed integer and does not have a problem with dates before 1901 or after 2038)