Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

Mary · 2006-08-10 14:52:57

Running into this problem again just now, I went into the Sections tab and changed the Default page and stylehseet, and was given this response: “Section name already exists”—though I had not made any changes to any section names or created any new ones.

Alicson: that should be fixed now.

Mary · 2006-08-10 14:59:35

I don’t know if this is supposed to be like this but in diagnostics I get this on top of the text field and they are all in red…

Yes. It’s a warning that you’re running svn files on a live site. :)

Mary · 2006-08-10 15:01:33

Is the n.setAttribute(‘id’,’{$wraptagid}’); (from dom_attach(), here ) snip going to make it into the final 4.0.4 release? I think that this would be greatly useful for further manipulating the DOM.

If it remains in svn, yes. (I don’t think it wouldn’t remain, but some things could get backed out if they cause more problems than they solve. ) :)

Mary · 2006-08-10 15:06:24

I made changes to a stylesheet and found that the changes were not being reflected whatsoever, though the old styles were still showing nicely.. I finally went into the Sections tab and changed the page and stylesheets being called to different ones, and then changed back to the correct ones, and found that this solved the problem and updated the styles properly.

In your prefs, do you have “Send Last-Modified header” set to “Yes”?

maverick · 2006-08-10 16:58:20

Is this an issue related to the changes in the subversion linked above?

Ben Bruce’s Email On Post (EOP) is returning the following message at the bottom of the write tab:

Notice: unserialize() [function.unserialize]: Argument is not a string in /home/.jabot/morch/moroccochurch.org/textpattern/lib/txplib_misc.php(501) : eval()’d code on line 122

I had not noticed this in earlier versions of 4.03

Destry · 2006-08-10 18:05:45

“testing” and “debugging” mode will allow saved article edits to reflect in front-side view of published article, but not “live” mode.

Send last-modified header was/is set to “yes”. Using rev 1667 on a local server.

I made three instances of edits/saves to an old article. The first time the edits reflected in the front-side view of the article as expected. The second time the new saved changes didn’t reflect. I tried repeatedly to resave, clear cache, whatever…no doing.

I then changed from “live” to “debugging”, and then refreshed the article view again and this time the changes appeared. To double check, I changed back to “live” mode and made some more test edits to the article. The changes did not reflect as before. I changed mode to “testing” this time, refreshed the front-side view and, voila, changes appeared.

Didn’t see any debugging or error messages in either debugging or testing modes.

Normal? Never had to do all that back-and-forth in earlier versions.

Last edited by Destry (2006-08-10 18:14:26)

Destry · 2006-08-10 18:55:02

colak wrote: I don’t know if this is supposed to be like this but in diagnostics I get this on top of the text field and they are all in red…

Mary wrote: Yes. It’s a warning that you’re running svn files on a live site. :)

I have a number of such diagnostic errors I haven’t had before, that one included. All of them have help buttons next to them, but none of them have any help text.

Anyway, a couple that have me scratching my head:

Some Textpattern files have been modified: /lib/IXRClass.php
site_url_mismatch: local.site.com\

Didn’t do anything with my paths. That’s about all I can say.

jonhicks · 2006-08-10 21:05:30

I’m also getting the following error in diagnostics on PimpMyCamino:

<p style=“color:red;”>mysql_table_errors: textpattern: warning: 5 clients are using or haven’t closed the table properly, txp_category: warning: 1 client is using or hasn’t closed the table properly, txp_file: warning: 20 clients are using or haven’t closed the table properly, txp_form: warning: 2 clients are using or haven’t closed the table properly, txp_log: warning: 28 clients are using or haven’t closed the table properly, txp_prefs: warning: 2 clients are using or haven’t closed the table properly, txp_section: warning: 1 client is using or hasn’t closed the table properly</p>

Sencer · 2006-08-10 21:24:42

Some prinicipal info about lastmod:

It is ~~almost~~ always disabled in testing and debugging mode, simply because when you are hunting errors it would only be irritating. The benefit is marginal, since production sites don’t run in that mode anyway. Hence only 304/Lastmod headers in live-mode
the option in pref has been non-functional until now. That explains why nobody has ever had any issues with it. If you prefer the old behaviour, turn it off. Then textpattern wil behave how it always has.
Browsers are doing their own caching magic – sometimes independant of what the website says it should do. They have heuristics to decide when to make a request to the server, and when to serve the request from the browser’s cache without ever asking the server about changes. Hopefully we’ll find something that works with less irritations for everybody.

Last edited by Sencer (2006-08-18 19:41:27)

Sencer · 2006-08-10 21:28:21

Jon, you shouldn’t worry about those, unless you are having problems. We try to check the tables for errors. If they are opened they cannot be checked. And that’s what textpattern is then reporting. Note that the diagnostics page is passing through a lot o information from the environment and other systems, so that’s why some messages may seem “foreign”. External stuff is usually best explained in the manual/documentation of those systems.

jonhicks · 2006-08-10 21:45:22

Thanks Sencer, everything does seem fine.

Zanza · 2006-08-10 22:23:43

Sencer wrote:

Some prinicipal info about lastmod:

the option in pref has been non-functional until now. That explains why nobody has ever had any issues with it. If you prefer the old behaviour, turn it off. Then textpattern wil behave how it always has. (..)
Browsers are doing their own caching magic – Hopefully we’ll find something that works with less irritations for everybody.

</blockquote>

I’ve had the same kind of problem, and didn’t imagine it could be due to lastmod preference. I set it to “no”, and everything started worked as usual again… good to know, thanks! :)

Z

Textpattern CMS

Textpattern CMS support forum

#49 2006-08-10 14:52:57

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#50 2006-08-10 14:59:35

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#51 2006-08-10 15:01:33

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#52 2006-08-10 15:06:24

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#53 2006-08-10 16:58:20

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#54 2006-08-10 18:05:45

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#55 2006-08-10 18:55:02

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#56 2006-08-10 21:05:30

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#57 2006-08-10 21:24:42

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#58 2006-08-10 21:28:21

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#59 2006-08-10 21:45:22

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

#60 2006-08-10 22:23:43

Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility

Board footer