Christopher J. Hradil

I’m cooking dinner right now, so haven’t had a chance to take a look yet, btw, what’s the URL for your site ?

thx.

I’m not sure I completly understand the problem you’re having. I know it’s a real pain (because you need the post ID’s, etc), but you should be able to provide working links using hte ?pxxx format if you can’t get your host to make things WP friendly or can’t/don’t want to switch hosts.

just a reminder, once your site is upgraded/installed/running properly, I would suggest (in your particular upgrade case) –
1) Make sure that the edits/changes you made don’t have a negative effect on the running WP 2.x.x install, and replace the files with the default 2.x.x files if needed.

then in general – for everyone –
Once the site is installed/running properly, do yourself a favor remove or rename all upgrade/install files from the site.

I’ll take a look at the code when I have some time this evening, until then, if you need to have your site back up and running all you need to do is either rename or delete the directory/file for the plugin causing the problem.

best…chris

First of all, let me start with a note, for my personal install of wp (which I haven’t had time to complete yet)
https://www.hradil.us/index.php (if you wipe out the index.php part, it takes you to my “old” mostly static site which I’m porting to wordpress/xoops., I just have so many other projects going on I almost never get the time to update my own stuff), anyway, back to the point, for my install, I’ve wiped ALL of that code out(’cause I don’t need it). If memory serves me correctly if you do choose to remove it, the default stylesheet should take care of the header display, although I’d have to go back and check my notes on that. I would take it out, see what happens, then if it doesn’t work the way you’d like, just put it back.

All of the themes/templates that I develop for clients/or dontation to the various communities are purely css based and remove all of the previously mentioned code from header.php. I like to build themes/templates/layouts that completely separate content from design/layout, it makes life much much easier in the long run.

Part of the point of my last post was to illustrate something reasonably important for everyone to be aware of, even though, the css/xhtml generated by something like the default themes of wordpress/xoops, etc, there is MUCH worse out there. As I mentioned, I’ve had a number of friends ask me to help them clean up the errors/user problems they’re all having with some pretty busy sites, and I’ve taken the postition, that until they migrate to a platform (wordpress,xoops,etc) that is at least capable of generating clean code, I’m not going to waste any time chasing down TypePad/Moveable Type code problems, the issue is pretty much the same, only much more complicated over there.

Part of the beauty of wordpress, is that with very few simple edits to something like the default (kubrick based) theme, you can at least start to develop your own theme from a platform which generates valid code.

In terms of a “tip”, what I’ve done is cleaned out copies of the kubrick based “default” and the wordpress classic themes, I use those clean copies as a starting point for developing new themes, rather than starting the whole process from scratch (which really isn’t that difficult, but since some of the “generic” standard portions of the original themes are just fine anyway, there’s no sense re-inventing the wheel). I have on a couple of occaisions had to start from scratch because the folks I was working with were using designs/layouts for thier sites that were just easier to build form scratch.

Another suggestion, I also belong to the community at https://www.oswd.org (open source web design), I have a couple friends/favorite theme authors there whom I’ve worked with in porting various themes found there over to wordpress/xoops. This also isn’t that difficult a process and depending on the functionality and layout needed for your site, might be a better option than starting from scratch.

are you trying to add a left side bar to the theme at your url ?

A postscript —
I hate to even think about the amount of hours I’ve spent over the past couple years cleaning up the code from wordpress/xoops/coppermine/phpBB, etc.

I have always been an advocate of standards, and am sometimes a little obsessive about serving clean code, but I believe that in the long run it’s worth it.

I have a meeting this week with some folks who run an EXTREMELY popular and busy blog site which they built with MoveableType/TypePad, thier technical person spends probably an average of 3-4 hours per day chasing user complaints based on the same kind of errors, who can’t see what, etc.

check this out —
https://validator.w3.org/check?uri=www.baristanet.com

that’s what TypePad/Moveable Type spews as it’s “default” standard code.

that’s not the half of it, I have things like opera and most of the mac stuff turned off in my style checker, as well as the CSS1 definitions. With all of that enabled, it would probably double the amount of errors/warnings.

Keep in mind, the style check used there is the same as the w3c validator plus has the additional capability of breaking things down by CSS1/CSS2, “safe”, and by browser/version/os, etc. So many of the warnings don’t really mean much. The errors are the key and are more likely to be the reasons for differences in how a browser will render a particular document. So that’s where I’d start.

As I develop themes for things like WP or xoops, etc. I validate them as I go, and check them with a couple of browsers so I’m sure things look as I intend them to in all/most browsers.

As long as you stick to the standards, your pages/css should always display almost identically in each major browser anyway.

In your particular case, the site looks quite nice in FireFox/Netscape, but does have some problems at the moment in IE. Keep in mind that with css, there are always more than one way to accomplish the same thing, so you just need to find the method which will be accepted by at least the two big browsers to achieve the effect you’re looking for.

My personal preferance is always to use “longhand” css, instead of single line declarations, nesting multiple elements, using child elements at all, etc. It’s a bit more work, and produces a larger css document, but is worth the effort in the long run because it’s easier to make additions/changes, and you need to waste almost no time at all chasing cross browser compatibility issues.

I agree with the previous posts about disabling WP caching whilst working on the site, but I would like to add that the Yahoo (and a number of other large hosting providers) employ dynamic content caching systems globally load balanced, — english translation, they store you’re php output as “html” in a caching appliance at various sites globally in order to reduce overall network traffic for duplicate requests, you might also consider “pragma-no-cache” headers, in order to avoid the caching servers/appliances completely, at least while working on the site.

One of the “quirks” of most of the caching systems used by the Yahoo’s/Aol’s, etc of the world is that they generally work very well with things like the “timestamp” or time modified on html files, and so will reload them almost immediately upon seeing timestamp changes, ironicaly, dynamic content from php files get caught in a “loophole” in that system, so it can take some time before the cache “reloads” the content. css files are treated as html files with regards to time modified, so will reload almost immediately upon changes.

Almost all large hosting providers AND ISP’s are using some type of caching or other these days (I’m on a comcast cable modem, and they use caching extensively, fortunately (for me), it ignores most dynamic content), AOL is about the worst, yahoo is probably somewhere in between.

I use CI-HOST for hosting a couple of dedicated servers and co-location, I’ve been with them for around 6 years, and they’re really great. They too, “optimize” thier network with caching however. So, my point is, that it’s almost impossible today to avoid having your content cached somewhere (especially images).

For sites where I’m either doing lots of work, or I want to ensure users are getting fresh content, I use some/all of the following –

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> and/or
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE"> and/or <META HTTP-EQUIV="EXPIRES"
CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">

So, as I mentioned, while wp “caching” could and likely is part of the issue, the various caching servers also have an impact as well. It’s worth noting, that if you’ll be using any of the meta tags, the “pragma” tag from HTTP/1.0 has more or less been depreciated by the “cache-control” tag in HTTP/1.1, so for most caching servers that would be the more effective and preffered method of controling how/if your content is handled.

Part of the issue with the caching servers at the moment, is that your php generated content is handled differently than a “known” file type like .jpg, .htm, .css, etc. The caching servers basically store your php generated content as something like http-your-url-content-php.htm

I have some previous experiance with caching and load balancing, and this all really became apparent to me in the past year or so as I had a number of AOL users contacting me saying, I made a post and keep hitting “refresh” or “reload” but I my post doesn’t show up for hours.

If anyone needs/wants any further detail on the caching server process employed by the web hosting/isp companies, feel free to contact me at chradil at comcast dot net with your questions.

here’s your problems –

https://www.hradil.us/sandbox/0709.html

you can remove all of the css including comments from the php templage file.

if you’re talking static links, you’re probably better off just going ahead and hardcoding them into the sidebar.php file for your theme, if they’re dynamic links, i’ll need to take a look at the specific plugin you’re talking about, do you have the url for the plugin ?

I think this one should do the trick, you would just need to specify a certain user level for registered users, and another level for un-registered, then the point of the module is to restrict access to categories/areas based on user level —

https://blog.firetree.net/2005/08/25/viewlevel-20/

I’m pretty sure it’s option_id 20, default_comment_status in table wp_options and comment_status in table wp_posts