[2.0] Restructuring the backend

Mark threads with "[2.0]" for discussions about features in the longer-term future, "[1.6]" is for short-term. This is not the place for general discussions or plugin or template requests. Only features that are approved to happen by the core team should be listed here for better structuring.
User avatar
yellowled
Regular
Posts: 6986
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Restructuring the backend

Post by yellowled » Thu Feb 16, 2012 2:49 am

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. :mrgreen:
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
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
onli
Regular
Posts: 2187
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Restructuring the backend

Post by onli » Thu Feb 16, 2012 2:59 am

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.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Restructuring the backend

Post by Timbalu » Thu Feb 16, 2012 10:26 am

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! :wink:

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?
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 6986
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Restructuring the backend

Post by yellowled » Thu Feb 16, 2012 11:47 am

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
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Restructuring the backend

Post by Timbalu » Thu Feb 16, 2012 12:24 pm

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.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 6986
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Restructuring the backend

Post by yellowled » Thu Feb 16, 2012 3:03 pm

Timbalu wrote:Confusing is, how you like to read me!
need to be named "trunk"
didn't make any other sense to me.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Restructuring the backend

Post by Timbalu » Thu Feb 16, 2012 3:33 pm

...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.
todoadminincs.zip
(23.53 KiB) Downloaded 324 times
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2187
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Restructuring the backend

Post by onli » Thu Feb 16, 2012 3:46 pm

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?

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Restructuring the backend

Post by Timbalu » Thu Feb 16, 2012 4:01 pm

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.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] Restructuring the backend

Post by garvinhicking » Thu Feb 16, 2012 6:09 pm

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
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
onli
Regular
Posts: 2187
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Restructuring the backend

Post by onli » Thu Feb 16, 2012 9:15 pm

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

@Ian: go ahead ;)

User avatar
onli
Regular
Posts: 2187
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Restructuring the backend

Post by onli » Fri Sep 20, 2013 5:42 pm

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?

User avatar
Don Chambers
Regular
Posts: 3626
Joined: Mon Feb 13, 2006 3:40 am
Location: Chicago, IL, USA
Contact:

Re: [2.0] Restructuring the backend

Post by Don Chambers » Fri Sep 20, 2013 10:22 pm

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.

User avatar
onli
Regular
Posts: 2187
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Restructuring the backend

Post by onli » Sat Sep 21, 2013 2:27 pm

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.

User avatar
yellowled
Regular
Posts: 6986
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Restructuring the backend

Post by yellowled » Sat Sep 21, 2013 6:15 pm

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
amazon Wishlist - Serendipity-Podcast (German only, sorry)

Locked