Serendipity Forums

onli wrote:We would simply store the tpl not in the template, but in iclude/, and hardcode the path, therefore it could not be overriden by anything.

You should definitely consult Garvin about the technical details, I didn't get half of the stuff he told me about it.

onli wrote:I think that this lockdown would be unnecessary if we simply decide to only mantain one admin-backend.

Well, the current backend is kind of the reason why there haven't been more admin themes in the past, so here's hoping this solution will ultimately produce more.

onli wrote:If we go that way, shall we already put it in trunk?

No, by all means, put this in a seperate branch of master. This is definitely a 2.0 feature, it's not a good idea to put this into master since master will be the source tree for 1.7, 1.8 and 1.9.

Unfortunately, I can not give any advice as to how to work with branches – haven't gotten around to that part of git myself.

YL

This is definitely a 2.0 feature, it's not a good idea to put this into master since master will be the source tree for 1.7, 1.8 and 1.9.

Sure about that? I was under the impression that 1.7=2.0. Never used branches with git, but it seems to be easy enough though.

Yes, master is always the bleeding edge in my eyes. The news file header should cover that and need to be named "trunk", as it is trunk, until a release version is tagged.
So, if you need to cut of a 1.7 branch, do it now.

But stop, before we do things like this, we could just clone the repo and experiment with smartifying the backend there. If that fits into trunk at its time, we just push it back and then split of a version.

But we are opening "something we can't return", as it is public...

I do understand Garvins concerns regarding the backend, but this is like the argument everything has to stay compatible for ever, even if not (or any more) officially supported. Like there are individual serendipity installations out there, making use of non-public plugins, which could possibly break with a new core version. (Just because someone got a very specific S9y site, made by a developer or his own mighty!) ... I don't think his concerns are the last word in this case!

Personally I have to admit this will happen sooner or later, if the feature "backward compatibility" brakes development!

Back to the backend templating. Having an internal lock is a good idea to stop designers to spread unmaintained backend templates, to avoid nightmares. But to be honest, in real its the same as we have now, just added by another abstraction level! Is that worth the work?
I do think doing this would be fine, because I think the core might benefit from being freed used as a template engine. Perhaps this might help to abstract some php code in the backend section...

In the last. Having a templated backend does not need to wait for a far-far-away 2.0 version. Do we need to keep ideas in the backhand to ever get to a 2.0?

Timbalu wrote:Yes, master is always the bleeding edge in my eyes. The news file header should cover that and need to be named "trunk", as it is trunk, until a release version is tagged.

master is trunk in git. I don't see a need to confuse people with double naming conventions.

Timbalu wrote:But stop, before we do things like this, we could just clone the repo and experiment with smartifying the backend there.

Or fork it and send a pull request later. Not sure what the best alternative, though.

Timbalu wrote:I do understand Garvins concerns regarding the backend, but this is like the argument everything has to stay compatible for ever, even if not (or any more) officially supported.

I assure you, with proper HTML markup, there is no actual need for more than CSS to style admin themes. This is really not the point to start a discussion about backwards compatibility.

Timbalu wrote:Is that worth the work?

I'm still okay with doing an HTML prototype which can be ported into the core PHP files later. Depends on how much work smartifying the backend actual is. I can't estimate that.

Timbalu wrote:Having a templated backend does not need to wait for a far-far-away 2.0 version.

Branching or forking the master now does not mean the backend won't make it into the core earlier. That's just to make sure we keep a clean master as long as we're still figuring the whole backend thing out.

YL

yellowled wrote:master is trunk in git. I don't see a need to confuse people with double naming conventions.

...thats what I said. Confusing is, how you like to read me!

yellowled wrote:This is really not the point to start a discussion about backwards compatibility.

Again, I did not start it..., but essentially this is the core point of discussion regarding Garvins concerns.

Timbalu wrote:Confusing is, how you like to read me!

need to be named "trunk"

didn't make any other sense to me.

YL

...the headline in the CHANGELOG NEWS file says "1.7" instead of "trunk"/"master"...

Well, to push some things forward, I dropped you all relevant admin template and already converted tpl files without the most confusing PHP parts as html files (mainly) to this zip. Rewriting this html stuff as it appears in order, to fit into a HTML5 structure without inline-css, wouldn't be too complicated and would solve the biggest part of all html output of the backend. This is what I meant saying, "grap the files and work in them, right from the beginning". Its not cleaned up 100%, but is worth to start, starting with index.tpl. Keep the <?php ... ?> parts I left, as they and where they are. After converting these changes back into the core files, they will need some polishing and finetuning for sure, but most of the rough work is done, I assume.

Well, to push some things forward, I dropped you all relevant admin template and already converted tpl files without the most confusing PHP parts as html files (mainly) to this zip.

Think that is highly confusing :) And I wouldnt know what to do with the html-files.
Let's structure this. I will start a new thread with a list of all the admin/*.inc-php-files and mark there which ones are already done. You already finished index and entries?

Well these files were not intended to open in a browser... I just thought them to be easier for YL to work with...

onli wrote:You already finished index and entries?

No.
These have been part of core for ages... look into /templates/default/admin/* including some media panel tpl files. If someone would have wished, they could have been boilerplated easy enough.
But via the dashboard P.o.C. I made some experiences converting comments (approved/pending) and entries (draft/futures) to Smarty.

Hi!

Sorry, no time, but: This definitely needs to go into its own branch. Once it works properly we can merge it into the s9y trunk.

We are not creating a 1.7 branch now, this would mean we would have to backport bug fixes etc. to 3 places (1.6, 1.7 and trunk).

Regards,
Garvin

I created a 2.0-branch and commited what i have so far.

@Ian: go ahead ;)

An addition:

In the beginning, we talked a lot about restructuring the backend. The work we have done so far is more in line with an iterative approach - the current backend was improved upon without changing much of the old structure.

That said, it might be worthwhile to build an additional backend which uses all the new stuff we built, which builds upon the new backend and therefore on the old, but which changes a lot more. Which tries new ideas and designs.

Something like that should be optional. But adding a new template just for a new backend? That doesn't sound good. So I'm thinking: Maybe we should have a way to select the backend-template independent from the frontend-template?

onli wrote:Maybe we should have a way to select the backend-template independent from the frontend-template?

I am definitely in favor of that. I proposed the exact same thing six years ago. I think the designers out there could have some fun focussing on a backend/admin template without the need for a corresponding front end template.

Nice "midterm" solution ;)

That's probably something that simply should be done and its details discussed then, but if anyone wants to chime in (where to place it? what makes it more complicated then I think atm?) or wants to declare he will code it (I won't have time the next few days or weeks, depends), now is a good time.

I'm not sure if this a valid reason or even something we should be concerned about, but I for one would much rather get one backend done before even thinking about building another one. And I would prefer to have every ressource (e.g. developer time and energy) spent on this one for the time being.

(In fact, I have sworn multiple times on Twitter that I would never do a backend again while doing this one.)

YL