Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
Sencer wrote:
Hi Jon, this will appear when
< ?
is used. Those have been deprecated for quite some time, and were initially intended to be removed for the 4.0 release last year. It is better to use<txp:php>
. There is an FAQ entry on it. We decided to introduce a warning to gently push ushers to the new tags. Having said that – it’s only a warning, not an error. So switching to live mode will make it go away.
I did have a < ?
in my comment_form that I’ve now changed to use the new tags, but that hasn’t removed the error. I’ve been testing and I’m sure its something to do with the live comment preview plugin….
Last edited by jonhicks (2006-08-08 22:54:04)
Cheers,
Jon VC#9
Offline
#14 2006-08-08 22:44:07
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
RSS Feed validates with one warning: “Avoid content:encoded”
Can you post or email a link please?
Alex
Offline
#15 2006-08-08 22:55:11
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
I’ve started adding FAQ entries for 4.0.4.
Alex
Offline
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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
Site: placenamehere.com
Microformat Plugin: pnh_mf
Offline
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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
Site: placenamehere.com
Microformat Plugin: pnh_mf
Offline
#18 2006-08-09 00:32:09
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
…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.
Offline
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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….
Site: placenamehere.com
Microformat Plugin: pnh_mf
Offline
#20 2006-08-09 01:02:44
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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.
Offline
#21 2006-08-09 05:11:01
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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.
Alex
Offline
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
Offline
#23 2006-08-09 06:43:49
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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.
Alex
Offline
#24 2006-08-09 13:36:00
- alexandra
- Member
- From: Cologne, Germany
- Registered: 2004-04-02
- Posts: 1,370
Re: Help.Textpattern 4.0-20060824.zip, backwards- and plugin-compatibility
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)
Offline