Serendipity Forums

I made a simple staticpage-plugin. It is probably indeed too simple to exchange the original with it. It needs testing, especially with mod_rewrite. And so far, it has no styling apart from some classnames and ids. Will only work with smarty 3, so it needs s9y 1.7.

But: Fully smartified, easy workflow, no clutter, easy to enhance (270 loc).

Hi, I just read your blog post and I will try to test it, but not in the next couple of days, sorry. Maybe we can talk about during the dev sprint.

All I'm about to write may sound stupid, be technically not feasible and/or is by no means meant as criticism towards the simple static page plugin (which I haven't tested yet). Bear with me.

Can't we just “re-use” functionality which is currently used for entries to create static pages? I mean, basically a static page is not that different from an entry. A static page is supposed to have a title and an url created from the title. It also has a publishing date, content (entry) and pre-content (extended entry). We could even use the category functionality to assign categories with static pages. Obviously, static pages don't need most of the features provided for entries by plugins like tags, extended properties etc., but the only actual difference (as far as I can see right now) is the fact that static pages are not ”presented” in a chronological order.

Does that make any sense at all?

YL

That makes sense, I thought about it.

The difference between static pages and entries I saw is exactly that some things are not needed, especially that the page is not in a context sorted by date. The URL shall look like a stable URL and can be/should be easy to add to the template-navigation. And the not-needed things are which make it easy to write such a plugin, I for example removed the pre-content on purpose (which function does it serve on a static page? None at all, as far as i can see).

We could probably save a staticpage as an entry with a specific publish-status or something else which hides it when fetching normal entries. But given the plugin-code to talk to the database is really not long (4 short functions), i don't see that big an advantage in this.

onli wrote:The difference between static pages and entries I saw is exactly that some things are not needed, especially that the page is not in a context sorted by date.

Sure, but it's still supposed to have a date (as “last edited”).

onli wrote:But given the plugin-code to talk to the database is really not long (4 short functions), i don't see that big an advantage in this.

I have no idea whether that would be an advantage, I just thought I'd mention it. Also, if it's not a plugin, it wouldn't need to be installed seperately. It sort of would be “in the core by default”.

YL

A remark: I just got notified that my static pages where not working, showing my projects and such. And indeed: they didn't work. What happened was that they were set to be a draft. I never noticed.

Seems for a very long static pages were viewable by all regardless of draft/publish status. Many people, me included, had several static pages with a draft status. Some fix to the static page plugin not long ago corrected this behavior - draft static pages were no longer viewable until published, as they never should have been.

Which explains why I didn't notice when making those pages. That fix wasn't such a good idea -.-

Anyway, there is a lesson here for the simpler version of the plugin: Draft-state shouldn't exist in this form or be very noticeable.

Drafts are IMO a very important feature so that you can hide pages. IMO this is not optional for a future plugin...

Regards,
Garvin

If that be so, that status should be very noticeable - specific styling on the page itself and an icon or specific placement on the backend.

But as the pages are listed nowhere in the frontend, which function fulfills that status?

garvinhicking wrote:...not optional for a future plugin...

What does that mean? Did I miss something? Is there an agreement to drop the old staticpage plugin and write a new one?
If someone heads there... I have to state that I would prefer to stick with the old and modernize it via a really simple template (something like the one Malte has in mind) and rename the current 'simple template' to more specific 'all field (structured)' template, or put the whole staticpage functionality into core.

Btw, I can't find any fixes of draft in last commit hist... or is the added $is_staticpage var meant?

But as the pages are listed nowhere in the frontend, which function fulfills that status?

But that's exactly the reason; people would need to be able to temporarily disable static pages if they need to work on it or if they are not yet finished.

I agree, the status indicator could be much more visible.

Regards,
Garvin

Ok, temporary disabling, especially after the page was online before, is a very valid usecase. Will be included.