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

placenamehere · 2006-08-09 00:17:12

did tag builders change in this version? just installed my microformat plugin on a clean build to test the DOM changes (which are fine with no plugin changes) but i see that all of the tag builders that I add with the plugins result in blank windows so I’d love to know what I’m chasing here.. bug or some admin side change I missed the memo on

placenamehere · 2006-08-09 00:21:40

zem: I respectfully submit that the FAQ items for the comments form get some editing before the release goes out.. its making my head hurt trying to figure out what got replaced by what and if its going to impact my custom templates.. its just so many different tag names you’re throwing at people at once.. though I’m not sure I understand the changes enough yet to make suggestions

Mary · 2006-08-09 00:32:09

…the FAQ items for the comments form get some editing before the release goes out

They always are kept up-to-date with every release. Don’t panic. :)

…its just so many different tag names you’re throwing at people at once

There are no new tags, it’s the same ones we’ve had (in the stable version of Txp) for a while.

did tag builders change in this version? …but i see that all of the tag builders that I add with the plugins result in blank windows…

They did. They had to (too long to go into).

Tagbuilders have never had plugin hooks or documentation on how to add new ones, so it wasn’t expected that we’d need to warn anyone about it specifically – aside from the several warnings given weeks ago to check plugins against svn.

placenamehere · 2006-08-09 00:41:14

Mary.. as for the FAQ item i meant the newly added 4.0.4 comments form change item… I know things are kept to date.. i just thought the brand new item needed work.. because as someone who had done a few non-default tempalte comment forms ages ago all of the various tag names were merging together in the explanation given there

as for the tag builders.. UGH! (not directed at you.. just at me finding this now when I am buried in MoreImportantTM things)

one simple change is the flip from “name” to “tag_name” for attributes to the initial request (e.g. old request was: http://txplatest:8888/textpattern/index.php?event=tag&name=pnh_mf_adr ) but there’s something I need to go digging into the code for cause the tag isn’t being built properly even when the proper initial form gets displayed

And I realize there was no API and these things happen… but the whole app plugin wise has been — and continues to be — mostly ad hock PHP hacking and inserting… I saw the warnings about dom changes and things looked ok there.. i just didn’t catch any other warnings about the tag builders. Again.. not grumbling at anyone in particular….

Mary · 2006-08-09 01:02:44

I realize it’s frustrating. Unfortunately, it’s what happens sometimes when you need to rip out incorrect, buggy and inefficient code and replace it with something better: anything that relied upon it needs to change too. Otherwise Textpattern – or any software – wouldn’t become a better app, it’d stagnate.

zem · 2006-08-09 05:11:01

Regarding the comment change FAQ, I updated it to say:

None of these changes should affect the default template code distributed with Textpattern. In most cases you won’t notice any differences. There’s no need to change anything or understand the changes unless something is broken.

If you do need to delve into the comment tags to fix something, then we’re going to have to talk technical.

wet · 2006-08-09 05:17:04

zem wrote:

Can you post or email a link please?

This one.

zem · 2006-08-09 06:43:49

Thanks.

Avoid using elements in namespaces when there are already core elements that do the same thing. The item contains an element that duplicates the semantics of the description element. Be advised that clients will behave unpredictably in the presence of such an element: some will prefer it over the description element, others will ignore it, and the behavior may depend on the order in which such elements appear in the item.

Bloody marvellous. description doesn’t duplicate the semantics of content:encoded, and the spec is a steaming pile of donkey turd.

(No offence to you, Wet)

It’s a warning, as you said, so we’ll take the position that the feed validator is mistaken on this point.

That said, if anyone can suggest a better arrangment of “description” and “content:encoded”, now is the time to make yourself heard. (By “better” I mean “more useful” or “more widely supported”, not “it’s what some guy said”).

The current situation is to make ‘description’ and ‘content:encoded’ exactly mirror Atom’s ‘summary’ and ‘content’. That is:

In “short feed” mode, only the description/summary is included. It uses the Excerpt, if available, or Body if it is not.

In “long feed” mode, both the description/summary and content:encoded/content are included. The first uses the Excerpt, the second uses the Body. If either one is empty, it’s not included at all.

alexandra · 2006-08-09 13:36:00

Hi Sencer, kbbu.de is still running on 1.RC0. If it should be necessary i can install 4.0.4 upon 1RC0. Just an offer for help…
(i am out of town next week, so let me know before or after)

jonhicks · 2006-08-09 14:02:00

BTW, I haven’t said thankyou for all the new admin features. Being able to see image IDs and search everything is superb!

placenamehere · 2006-08-09 14:14:21

so it looks like the issue with the admin side plugin with tag builder functions is just the variable name moving from “name” => “tag_name” throughout the tag builder code (can’t bring up the first form without the tag_name, can’t find the proper builder function without the tag_name getting passed to the next page which doesn’t happen if you don’t global the right vars etc… makes sense

but it leaves me looking for a good solution to deal with backwards compatability here… besides doubling up all the variable names and hoping I don’t bust anything or cause any other problems by doing things like re-adding $name in 4.0.4 after you’ve had cause to remove it. Any thoughts?

Also, I’m still curious about what changed — if anything beside the variable name — that I could take advantage of. I didn’t notice any additional work in this area just from skimming the code and it looks like to get this stuff working in general the only way is to continue to insert the same tag_blah_blah_blah() functions I have been in the past. Is there more coming in future versions? Something I’ve missed?

Mary · 2006-08-09 15:15:37

It was because “name” is a tag attribute.

alicson · 2006-08-09 18:50:14

Hi, I’ve run into some sort of issue regarding the call of stylesheets to corresponding sections…

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.

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.

Zanza · 2006-08-09 21:53:12

In test mode I get some warning from chh_article_custom plugin. In live mode, although, everything works, with one exception: the date format wording are in english, where in the previous version they were in italian!

The tag I use: <txp:posted format="%B %Y" />. Maybe I should set something in the admin tab? Any hint?

Apart from this, everything seems to work! :)

Z-

Sencer · 2006-08-09 22:02:06

Hi alicson, nice to see you again ;)

in advanced preferences, please set “Send Last-Modified header” to No. That setting was previously non-functional, it was only fixed recently. If you know how to check HTTP-Traffic, you maybe can help debug the problem in this thread r1622-1626: lastmod.
Quoting your post from here, and adding which Browser you are using would help.

Zanza: The locale is set accoring to the selected language. If it is set to english, so will the dates appear. If you have it set to italian, try switching to a different language, saving, then switching back to italian. There haven’t been any changes in that area, so it’s unlikely that code changes are responsible.

Textpattern CMS

Textpattern CMS support forum

#16 2006-08-09 00:17:12

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

#17 2006-08-09 00:21:40

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

#18 2006-08-09 00:32:09

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

#19 2006-08-09 00:41:14

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

#20 2006-08-09 01:02:44

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

#21 2006-08-09 05:11:01

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

#22 2006-08-09 05:17:04

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

#23 2006-08-09 06:43:49

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

#24 2006-08-09 13:36:00

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

#25 2006-08-09 14:02:00

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

#26 2006-08-09 14:14:21

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

#27 2006-08-09 15:15:37

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

#28 2006-08-09 18:50:14

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

#29 2006-08-09 21:53:12

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

#30 2006-08-09 22:02:06

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

Board footer