Better support for "static pages" by hiding sections on the write tab

anoke · 2007-07-11 09:14:53

I think Mary was refering to privileges system itself (i agree it is needed – yet i understand why devs won’t do it for 4.0.x).

“Can contain articles (yes) (no)” is about 3-15 lines of code I guess. Depends how those lines are counted. (1 for popup, 8 for section, rest for update)

But yes – I too have too many sections in my section menu (:

benbruce · 2007-07-12 00:05:38

EDIT: redbot pointed out that I’m confused. This won’t fix your issue

What about just assigning each static section to page=“static” and then inside the page use something like:

<txp:if_section name="about">
<txp:article id="1" />
</txp:if_section>
<txp:if_section name="archive">
<txp:pulls_articles_according to the URL via rss_suparchive />
</txp:if_section>
<txp:if_section name="contact">
<txp:article id="2" />
</txp:if_section>
<txp:if_section name="tag">
<txp:pulls articles from the URL via tru_tags />
</txp:if_section>

That way you only have a single “extra” section in your dropdown¹.

Ben

¹ Where id=1 is your about article, id=2 is your contact article, and I didn’t know how you were doing the archive and tag sections, so I made up a placeholder tag for you.

Last edited by benbruce (2007-07-12 19:04:11)

Mary · 2007-07-12 03:19:04

I think Mary was refering to privileges system itself…

Not really, but that’s another argument against rushing inclusion.

…is about 3-15 lines of code I guess.

It’s more than that. You have to modify the database table, the sections and article tab. You also have to test it to make sure it actually works. There’s more to it than “how many lines does this add or change”. Once you’ve developed for a while you learn that lesson well. Remember, we’re the guys that not only have to make it, but support it. When we’ve rushed in features before it came back and bit us in the ass, multiple times. We had to go back and try and fix the mess without breaking it in other ways too.

In case it has been overlooked, I’ve said on several occasions that we’re avoiding adding new features to 4.0.x and shifted focus to the crockery branch. The more new stuff (features) added to 4.0.x, the more likely upgrading to the next major version (crockery) will be complicated, possibly broken, and that adds up fast (think large numbers of manual changes on your part for each site). Anything we add needs to be either a bug fix, or should be small and/or simple tweaks. It it in the user’s best interest that we be careful about 4.0.x feature changes, especially when adding them is only resolving a minor irritation (know that each of the developers run several sites on Txp, so we can totally understand).

anoke · 2007-07-12 15:21:07

Mary wrote:

bq. …is about 3-15 lines of code I guess.
bq. It’s more than that.

The whole diff I made was about 70 lines. It does (truncated) section titles instead of names ad hoc, which is adding lines. That new feature was asked too btw. (Tag builder’s section popper uses titles already. Is that the reason making the request semi-fixed and worth ignoring? Puzzling the consistency is.)

So – no. It really isn’t more than that. And do remember I said it depends how one counts those lines.

You have to modify the database table, the sections and article tab.

Yes, I did all those. Updated table with safe_alter, added radio buttons to sections, changed the SQL for section_popup().

You missed txp_tag.php btw.

There’s more to it than “how many lines does this add or change”.

Of course. Most of the maintaining is to have old code haunting. If I was a dev I sure too would like picking my nightmares. Yet features thrive on code.

In case it has been overlooked, I’ve said on several occasions that we’re avoiding adding new features to 4.0.x and shifted focus to the crockery branch.

Users have heard all versions of mantras devs have. Every “it’s in the crockery”, “perhaps in crockery”, “could be done in crockery”, “can’t be done” and their plugin-flavours. I wait for the “can be done in crockery with a plugin”. Not a very friendly way to treat suggestions and requests. This isn’t the first time making static pages easier is asked either.

Devs should say aloud 4.0.x is frozen, stop developing it and really leave it for bugfixes only. Instead of repeating that. Updating jQuery to 1.1.3 while repeating “bugfixes only” contradicts. jQuery isn’t that essential yet. But that won’t happen – freezing 4.0.x would make it officially deprecated and AFAIK crockery isn’t near primetime. So there wouldn’t be any fresh TxP flavour available. Not a very good move to grow userbase.

Besides, when has TxP seen a feature NIH anyway. Wet has said he don’t like such things (though on one subject) and it describes the concensus. Not getting more identifiers yet getting “<tr id=“branding”> supports that. Yes, I’m bitter.

Now to think of it – what features in the last 3 versions have come from users’ feature ideas/requests? “You don’t need that! There’s nothing wrong!” is a silly excuse. So is “we don’t get enough patches”. Why would someone like patching a deprecated branch if it’s clearly obvious patches will be categorically ignored in silence as useless?

The more new stuff (features) added to 4.0.x, the more likely upgrading to the next major version (crockery) will be complicated, possibly broken,

That’s a nice way to think features – something to avoid to make upgrading easy. Major versions often break stuff; how feature-less is a value beats me. It’s not about having all the features, it’s about having at least some.

and that adds up fast (think large numbers of manual changes on your part for each site).

Yeah, sounds bad. From experience I can tell it is – I have to patch and tweak every site I build with TXP already. And again after upgrading. I’m still running 4.0.3 because I too lack the time. It’s not a dev’s privilege.

It it in the user’s best interest that we be careful about 4.0.x feature changes, especially when adding them is only resolving a minor irritation (know that each of the developers run several sites on Txp, so we can totally understand).

I’m so awed with several. Ever thought that users might run several sites too? 5 installations has 7-15 users all needing to publish images and files. Not all users treat their TxP installations as “nice blogs”. If I had known TxP won’t scale over 4 bloggers I wouldn’t have picked it. Even selecting articles becomes a chore with over 1000 articles and 15 users, images and files are horrifying remembering it is year 1998. No, wait – it is 2007. It’s too late to pick another poison when it is running the system.

You see, even TxP users might have people to support.

benbruce · 2007-07-12 16:01:47

Whoa … Anoke … that was a pretty hardy rant. And to Mary and the others, I’d like to counter by saying your approach seems measured and careful, and correct. For me, it’s much better to have a seamless upgrade¹ than new features that I don’t need. Anoke, your feature request could be fulfilled by a plugin.

~~I’d just like to point out that a simple, straightforward solution was presented by me above, using existing TXP and not requiring anything but a little of if-this-then-that.~~

Ben

¹ I upgraded to 4.0.5 — getting the bugfixes and the security fix — without a single problem, in five minutes.

Last edited by benbruce (2007-07-12 19:04:34)

redbot · 2007-07-12 17:57:13

Ben,
probably I’m wrong but I’m not sure you understood what alesh was asking for. He was talking about the sections dropdown in the write tab so I think your solution won’t work here…

benbruce · 2007-07-12 19:02:45

redbot,

Yup, you’re right — I’m confused. I did manage to bring down the number of Pages, though, didn’t I?

;)

In any case, my point about the devs taking a measured stance stands on its own — I’d rather have them decline features they think will add bugs.

Ben

Last edited by benbruce (2007-07-12 19:14:50)

wet · 2007-07-12 19:32:09

anoke wrote:

Wet has said he don’t like such things (though on one subject)

It’s not about what I like or dislike, but about necessities. Maybe I was a little unclear with my opinion on additional element ids, but I tried to express that these are not generally necessary as most of the interface elements are easily found by a jQuery selection. And judging from your answer I thought you were content with my reply then, and wanted to start learning jQuery: $("form.search-form").

anoke · 2007-07-13 07:32:33

benbruce wrote:

Whoa … Anoke … that was a pretty hardy rant. And to Mary and the others, I’d like to counter by saying your approach seems measured and careful, and correct. For me, it’s much better to have a seamless upgrade¹ than new features that I don’t need

Yes, it was :( And true, 80% of people use 20% features. I still don’t get the “every feature will bring this shattering apart”-idea. Especially if some features are already implemented in the core since 404. Surely that is tested.

Anoke, your feature request could be fulfilled by a plugin.

Did you read the first page? It was said a plugin couldn’t do that. Yet it can be done, in a very “this is an awful mess, why I have to inject HTML, why there isn’t callback for section_popup function or category_popup?” way. Why should someone (like me) care asking for new core functionality to build plugins on if even the features that could be built are considered merely useless?

These aren’t the dro^h^h^h features your looking for, hm?

Wet: yes, and still am. jQuery is a total new thing (but got hooked already :) to me. The more I understand it, the more I wish for a few classes and ids though. Oneliners start wrapping.

hakjoon · 2007-07-13 14:15:09

Also remember that jQuery supports a lot of XPath type selectors. So you can do things like $("//div/a[href=‘http://www.textpattern.com’]”)@ and select links that point to texpattern.com or $("#article-col-1 h3.plain:last") to get the last header toggle in the left column of the write tab.

It gives you lots and lots of freedom.

Last edited by hakjoon (2007-07-13 14:21:37)

alesh · 2007-07-13 17:44:10

Personally, I have no problem waiting for version 4.1. After all this is a convenience feature, not something I need. If the developers recognize the usefulness and want to implement it at some point, I’m satisfied.

Personally, I think the “Can contain articles” option is less flexible then “Show section in write tab”, because it allows for the 1-article sections, sections that have articles added to them very infrequently, and for old section that has a bunch of articles but which is for whatever reason closed.

I’m not sure lashing out at the developers is helpful… they’re volunteering their time and it’s their prerogative to steer TXP in the direction they see fit. Managing this many lines of code, and this many competing interests and priorities, is more of a headache then I’d care to partake in, even for a handsome salary. Thanks to all the developers!

Mary · 2007-07-14 03:34:29

Devs should say aloud 4.0.x is frozen, stop developing it and really leave it for bugfixes only.

I have. We have. If you took 5 minutes to calm down and look at what’s actually happening, you’d see that. jQuery isn’t ‘ours’, isn’t used by 4.0.x and will not be. I fail to see how updating an external, an unused library, included for user convenience, is active development of a new feature.

Anyway, yes Alesh, we realize this can be handled better and we’re working to improve the situation. In the meantime, there are, as benbruce points out, ways to work around the current difficulty. :)

Textpattern CMS

Textpattern CMS support forum

#13 2007-07-11 09:14:53

Re: Better support for "static pages" by hiding sections on the write tab

#14 2007-07-12 00:05:38

Re: Better support for "static pages" by hiding sections on the write tab

#15 2007-07-12 03:19:04

Re: Better support for "static pages" by hiding sections on the write tab

#16 2007-07-12 15:21:07

Re: Better support for "static pages" by hiding sections on the write tab

#17 2007-07-12 16:01:47

Re: Better support for "static pages" by hiding sections on the write tab

#18 2007-07-12 17:57:13

Re: Better support for "static pages" by hiding sections on the write tab

#19 2007-07-12 19:02:45

Re: Better support for "static pages" by hiding sections on the write tab

#20 2007-07-12 19:32:09

Re: Better support for "static pages" by hiding sections on the write tab

#21 2007-07-13 07:32:33

Re: Better support for "static pages" by hiding sections on the write tab

#22 2007-07-13 14:15:09

Re: Better support for "static pages" by hiding sections on the write tab

#23 2007-07-13 17:44:10

Re: Better support for "static pages" by hiding sections on the write tab

#24 2007-07-14 03:34:29

Re: Better support for "static pages" by hiding sections on the write tab

Board footer