shelleyp

Those seem to be very clean styles, ready for people to modify as needed. I bet they would be rather uncomplicated to work with, too. Thanks for providing links.
I’ve always thought that it was more important to provide a clean template that provides basic layout that validates as XHTML as part of an install, than one that intimidates the user with it’s complexity and awe inspiring beauty.
Because beauty, awe inspiring or not, is in the eye of the beholder.

Does anyone have links to screen shots of these templates in action?

You’re right, rboren. And I’ve not been helping the process.
I think this is a good step in the right direction, and now that I better understand why you did what I did, I can see the reasoning for it. Yours is a traceability and accountability system — makes more sense now.
I am used to bug systems, which also act as feedback for testing, as verification of fix, requiring more communication. But that’s a different type of application process. As you’ve said, that’s not the direction you’ve gone, and I have no right to question this. All I’m doing is being a pain in the butt.
Good luck with it. It’s good to see you’ve incorporated a bug system.

The bug bouncing is my own unfamiliarity with this particular bug system.

Never mind. I thought my meta tag was set correctly, but wasn’t. Changed to
<meta http-equiv=”Content-Type” content=”application/xhtml+xml; charset=utf-8″ />
All better

The link ended up with a period in it and should be https://wiki.www.ads-software.com/WPBugs – Look down the page for 1.2 frequent problems & bugs. This is one of them.
Previous forum entries on this at https://www.ads-software.com/support/index.php?action=vthread&forum=3&topic=5757&page=0
https://www.ads-software.com/support/3/6368
https://www.ads-software.com/support/3/5287
And if you search on the function name, I think you’ll find other threads.
Supposedly there might be a 1.2.1 branch, and this might be fixed in it. And a suggestion has been made to use get_the_category instead.

This is a known problem. Check the WPBug page on the wiki, https://wiki.www.ads-software.com/WPBugs. Some people have came up with a workaround, but this function is no longer working, and rumor has it, no longer supported.

That’s what I’ve been suggesting–that the WP development map between the two for 1.3, rather than just pull the old names without backwards compatibility, and without overlap.
Unless the structure of the objects change, this mapping shouldn’t be a problem for the development team.
And if the structure of the objects change, then this is more than just changing the variable names, and there needs to be some discussion on this now, too.
And Beel, the nightly is a 1.2.x.

Yes, I saw that and updated my message just as you were coming in. As I said, that’s something.
But which branch is feeding the nightly builds? The 1.3 alpha? Which branch feeds the nightly build should be distinguished. All it takes in one rumor of an important fix in the ‘nightly’ build, and the build is 1.3a, to have a mess.

Codergurl, I misread, or Beel misread? Sorry, but when Model A is interjected without any other association, I have to assume its interjected in response to my suggestion.
But Beel did misread my underlying concerns when I talked about the problems this will cause. If the application comes out and these variables have been dropped, but people are using plugins that haven’t been updated, what will happen as soon as the people upgrade to 1.3?
There’s a massive assumption here that the plugin developers and others providing hacks are going to keep up with these releases. They most likely will — but they may not keep up to the speed that users download the 1.3 alpha, and then beta.
Look in the bug reports for 1.2. One of the significant ones has to do with supposedly deprecated functions that people are using.
The deprecation process traditionally, and I know that’s an ugly word, is to deprecate the object for one release, possibly two, while you also provide support for the new variable/function. Then you pull the old. The overlap provides for a smooth upgrade, regardless of who has updated their code. Then people can take their time about making the change.
What is the harm in doing it this way? A simple mapping to ensure smooth upgrades.

Thank you for comparing my suggestion on helping for a smoother upgrade to Model A’s and hand cranking.
True, I do have over 20 years of experience rolling out applications, which must make my suggestions seem old and outdated. Interesting, but the concept of deprecation is honored in most other open source applications — I guess they’re all Model As like myself.

You used the magic term with me
stop energy
I’m outta here with my stop energy

mf, I may back out a change you made in the wiki. You removed the separate page and placed all bugs on the main bug page.
But what happens when 1.21 comes out?
By linking on a separate page, we can keep bugs for each release separate.

I take that back — it has been edited.
But then where are bugs to be submitted that don’t have at least two responses?

As mentioned, create a copy of index.php and modify it to be your individual page.
If you’re using permalink pointing in .htaccess (generated on the permalinks option page), change the .htaccess entry for individual items to point to your individual.php page rather than index.php. That’s the only change you need to make.