Rongo

I stand corrected then. I had never heard the phrase.

That said, I run my primary monitor of 1280×1050 resolution and the secondary one at 1280×1024. I have to scroll to get to the categories whereas before, I could simply arrange the sidebar how I needed for maximum efficiency.

Simply put, 2.3.x allowed for all pertinent information/options to be displayed within a single screen without any scrolling, including the image upload functions and categories, author, posting date, adjacent to the posting screen.

In other words, the Write Page has, for me, taken a pretty big hit in terms of efficiency.

For a company that prides itself on attention to detail, this little tidbit caught my eye:

God is in the details.

https://www.happycog.com/design/dictionary/
Assuming that was supposed to be “good”, I found that humorous.

For the most part, I think Happy Cog did a decent job on the admin backend. However, the removal of the categories from the sidebar, and the hiding of the scheduled date until expanding it (for EVERY post you wish to schedule or backdate) were, in my opinion, just terrible decisions.

With that one single change to force longer scroll times, and to remove relevant information / options from view until you scroll or expand options, they have made other competitor’s software posting interfaces superior by comparison.

That’s a shame.

Thanks Otto. Hopefully the developers won’t blow it off as the responsibility of a plugin developer — a third party who has no obligation to the community to keep things updated.

If they refuse to provide the ID overviews again, they ought to at least revise the codex to say that users need to use mouseovers, status bars or address bar links to get the ID since it is no longer revealed in the admin areas.

I would personally LOVE to see an option for Imagemagick (allowing users to select which Image Library to use) as ImageMagick is, quite frankly, superior to GD — offering custom command line strings, image filters, not to mention the output quality is superior.

munky… or… you can try putting this code in the beginning of your index.php file, BEFORE any wordpress code.

<?
	// Check Domain and Change to Proper Spelling if Necessary
	$our_server = "site.com";
	$our_http = "https://www.site.com";
	if ( isset($HTTP_HOST) && !eregi($our_server, $HTTP_HOST)) {
		header("location: $our_http$REQUEST_URI");
		exit;
	}
?>

What this will do is check the incoming domain (site.com or site.net) and switch it to your primary one BEFORE loading the wordpress calls.

Please note, this must be used at the top of the index.php file, and there can not be any blank lines or spaces before any of it, or you’ll get a headers already sent php error.

Also please note, the above is provided with no guarantees. Use at your own risk. But if it’s any help, it’s what I use for to handle all domains pointing to my site (.com, .net, .us, .org, etc plus all my registered misspellings of my domain as well) and it works just fine.

Otto: for Link Categories and Post Categories, the codex is filled with functions that allow you to output data or formulate queries based on specific ID numbers. Even something as simple as a custom category template requires the format of category-##.php where ## equals the category ID number.

In 2.5, these ID’s have been removed from admin view, and now those who use these functions have to rely on mouseovers, status/url address bars, or viewing raw MySQL tables just to obtain the ID’s.

From where I sit, I respectfully disagree with your assessment — I think it is indeed a big deal.

Post ID’s are not that important, but do come into play for some folks.

Link/Post Category ID’s are, however, more important and there has also been a suggestion that you can obtain these by a mouseover.

To call this resolved is, in my opinion, a bit of a stretch.

What it really is, is a quick fix to an oversight.

The fact is, the codex offers a multitude of functions that make clear references to the ID numbers for category, link, or post, as one of the options available for that specific function. To remove the ID’s from view and require a mouseover is, at best, a quick fix to an otherwise fairly serious oversight.

It doesn’t take a lot of code to add an ID column in the Manage Categories page, or Manage Link Categories page.

A resolution to this is not a mouseover, but the ability to toggle ID visibility on or off.

Chris, I saw that already, thanks.

Really, I would guess that this is an oversight on the part of the developers. Or certainly I hope it is, as otherwise it’s pretty ridiculous to expect people to follow directions in the codex, with regards to category ID operations, by having them obtain those ID’s with a mouseover and reading their browser’s status bar.

Category ID’s are used in a variety of functions, not to mention they play a key role in custom category pages (category-##.php) where ## = the category ID.

If that’s not an oversight, then it’s a line of thinking I’ll not figure out anytime soon, and it essentially makes the entire codex documentation / examples out of date for any reference to category ID’s.

For those interested,

Location:
/wp-includes/media.php

On Line 178, Find:
$jpeg_quality=75

Replace with
$jpeg_quality=##

Where ## = a number greater than 75, and to a maximum of 100.

Please note, while this will increase the default quality of thumbnails, the file sizes will be bigger. However, for anyone that cares about quality images on their blogs, you won’t mind the trade-off. The default quality of the generated thumbs, on a hi-res monitor, are just atrocious. At least this gives you a chance to have presentable thumbnails. Use at your own risk, and make a backup of the original before editing core files.

An Ideal Solution
——————–
What would be an ideal solution is to let users choose if they’d like to use imagemagick or the default options. This would let users with imagemagick installed on their servers to specify the switches to apply sharpness, radius, contrast, etc on a single default variable string, as an Admin Option. This would produce superior thumbs, and, more importantly, give WP users a choice. But at the very least, allow users to specify a quality variable on the default options. 75 is simply inadequate to produce acceptable quality thumbnails.

Please Also Note
———————
Please do not suggest I use a plugin to address the quality issue. I’m interested in WordPress improving THEIR inherent image quality routines/options rather than forcing people to rely on plugins to address a [lack of] quality issue that they include as a default.

RyanWilliams: Wow, I had never seen Moveable Type’s admin area before and, I have to admit, this is what I expected of WordPress.

The functionality of MT’s Write Page is quite efficient — and logically laid out. No scrolling required to reach all necessary areas AND, categories and publishing dates/status are where they belong, on the sidebar alongside the post.

I’m absolutely blown away at how ridiculously bad the forthcoming Write Page is in WP2.5 — efficiency is greatly reduced. I’m on a 1680×1050 screen and I have to scroll just to reach the categories! And even then, I have to expand them because they are collapsed by default.

Quite frankly, I have come to expect better from WordPress’s development team. But wow, did they ever miss the mark on that Write Page, and I won’t even get into the step backwards of the Widgets page with removal of the drag and drop.

Colour me both unimpressed and disappointed. I expected better from WordPress than what they’re about to offer their community.

I’m not a coder Otto. And I am not sure which plugin came first. The SimpleTags plugin I use was available ever since 09/07/2005.

Anyway, that’s besides the point. The idea how it works is simply that when writing your post, you add the following:

[tags]keyword, keyword, keyword[/tags]

When you publish your post, the keyword are auto linked to Technorati.

I modified the URL in the code to instead perform a search for those keywords on my site. For example, I changed technorati.com to mydomain.com/?s= so that the keyword I link is now a search term.

However, after upgrading to 2.3, I am left with a couple of thousand posts each with unparsed code showing, quote literally:

[tags]keyword, keyword, keyword[/tags]

Where keyword is the actual keyword I had entered for that post.

My choices are to either edit every one of those posts, or run a custom query/script to delete everything after the open Tag bracket in its entirety — neither of which is appealing, as you can imagine.

I would really like to see an importer for the SimpleTags (plugin made by Broobles — https://www.broobles.com/scripts/simpletags/) into WP2.3. I have in excess of 1,000 posts all tagged using that plugin and was excited when I saw WP2.3 shipping with “Simple Tagging” importer.

Then when I tried it, I realized the importer was made for a different plugin, not the SimpleTags plugin.

It would certainly be appreciated if anyone can come up with a workaround, a plugin, an SQL query, or anything at all that i can use to import my tags.

Looking at the plugin author’s site, s/he is not responding to requests for a 2.3 importer, thus it appears those of us are SOL who used this plugin (*one major reason why I hate relying on anything not officially part of WP — with plugins, you use them at your own risk and development can cease at any time).

Anyway, if someone can offer a solution to this, I’d be thankful.

I don’t see why it matters, as the end result is still that wordpress defaults produce ridiculously crappy thumbs unless you force the higher setting. So the type of pics I am uploading does not exactly matter, the end result is still the same — I have to edit core code to get a decent quality thumbnail to be created.

That said, I’m using Jpegs (complex models) saved in resolutions of between 1920 and 3000 pixels (on their longest side). These files are saved with a Jpeg quality factor of about 85% from their original raw format, and are typically 1 to 2MB in file byte size.

Incidentally, I understand compression versus quality loss — I’ve been working with graphics professionally for years.

The simple fact is that relying on native PHP image resizing/resampling without specifying any quality options defaults to crappy thumbs. It’s bad enough that the thumb sizes/ratios are not selectable, but the thumb quality is so bad I can’t believe more people have not complained about it, as it’s embarrassingly bad quality.

As such, the solution is to either edit code myself, or hope the developers actually include a user selectable quality variable for the generated thumbs.

Is that even legal under Amazon’s affiliate terms of service agreement? I would assume this would fall under deceptive practices and would be cause for termination of the affiliate account of the plugin author.

Futurix, which is why I suggested a variable be used so that end users could select which quality works for them.

For me, I am uploading images with resolution of 1920pixels, and larger. Using a compression of 85 to 90 makes the generated thumbs look ridiculously bad.

For this reason, I am using a variable of 100 and have super clean thumbs. The resulting thumbs are about 7 to 10k each versus the 2 or 3k crappy thumbs WordPress generates by default. From where I sit, 4 to 7k is a pretty small price to pay for decent looking thumbs compared to the horrible quality of the default ones.

Quality matters.