Page 5 of 12

Re: [2.0] Smartifying the backend

Posted: Tue Mar 20, 2012 9:38 pm
by yellowled
Timbalu wrote:Not really. I didn't touch html code. Just corrected some bug.
Yes, but I edited the HTML. :D Nevermind, it's just some "Frickelkram" I have to get through. Probably way less worse than I imagine now.
Timbalu wrote:I don't get what you are talking about. Which changes earlier...?
I have versions of both files which you emailed me and which are different to the ones in 2.0 now. But I can't tell what changes are (still) necessary. I'll just email you copies of those.

YL

Re: [2.0] Smartifying the backend

Posted: Wed Mar 21, 2012 9:22 am
by Timbalu
YL, keep functions_installer.inc.php and erase the installer.inc.php file. My local copy of the last is exactly the same as in 2.0 branch, including Maltes last commit correction. The first is what we did together converting these two functions to fit into your concept. This file has to get a fallback..., as I said in my last post.

Re: [2.0] Smartifying the backend

Posted: Wed Mar 21, 2012 2:34 pm
by yellowled
So the proper way at the moment is

* get 2.0 snapshot
* install it
* replace functions_installer.inc.php with your copy
* replace/add admin tpl files

Why don't we just check your functions_installer.inc.php in the 2.0 branch?

I'll probably not find the time to work on this again before Monday when I spend another day on the train, so if you still need to make any changes …

YL

Re: [2.0] Smartifying the backend

Posted: Wed Mar 21, 2012 5:02 pm
by Timbalu
yellowled wrote:So the proper way at the moment is

* get 2.0 snapshot
* install it
* replace functions_installer.inc.php with your copy
* replace/add admin tpl files
Yes! [update]Move install to the end![/update] I personally did this to my local php files to switch more easily

Code: Select all

$tpldir = ( !SMARTY_VERSION ) ? 'tpl' : 'tplnew';
$tfile = dirname(__FILE__) . "/$tpldir/XXX.inc.tpl";
yellowled wrote:Why don't we just check your functions_installer.inc.php in the 2.0 branch?
Because nobody can use it until we have a beta prototype of the backend. It breaks the old backend by html5/CSS, that is why we have to find an easy way to fall back.
yellowled wrote:I'll probably not find the time to work on this again before Monday when I spend another day on the train, so if you still need to make any changes …
very funny! :wink:

But I am gone check in soon the typos and hardcoded things we just talked about.

Re: [2.0] Smartifying the backend

Posted: Wed Mar 21, 2012 5:12 pm
by yellowled
Timbalu wrote:
yellowled wrote:I'll probably not find the time to work on this again before Monday when I spend another day on the train, so if you still need to make any changes …
very funny! :wink:
Actually not meant to be funny, it's just easier for me to work on it if I don't have to update the 2.0 snapshot. :)

YL

Re: [2.0] Smartifying the backend

Posted: Wed Mar 21, 2012 6:44 pm
by Timbalu
I need some brainstorming in the fallback question...

Remember, we have at least two or more internal function to emit HTML5/HTML4 - they could be smartified to avoid breaking in different backends... (I still don't know this is possible or usable in each of them) but which keyswitch could be used to really always know which one shall be used? I tried with differing by SMARTY_VERSION, but this isn't safe enough, while it is still thinkable someone needs or wants to use the old or his own backend with Smarty3 though.

This Question follows into installer and upgrader, which need this very specific switch too.

How can we really know which one the "unknown user" wants? There might be the possibility to add an option to the serendipity config for this, but this does not work in installing or upgrading situations... We could overrule that by default, until the user sets this option var back to his personal choice...

Another option would be to stick to the old output by default, and have two tpl dirs, like I did locally to switch, until the config option "use new backend" is set to true...

Are there any other ideas to have this simple and failsafe enough, avoiding redundancies?

Re: [2.0] Smartifying the backend

Posted: Thu Mar 22, 2012 9:58 am
by garvinhicking
Hi Timbalu!
Timbalu wrote:I need some brainstorming in the fallback question...
I can't really understand. Can you provide a specific code example to illustrate the situation?

Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Thu Mar 22, 2012 10:10 am
by Timbalu
garvinhicking wrote:I can't really understand. Can you provide a specific code example to illustrate the situation?
Hi Garvin. Please see my small example two posts up! This should give a hint switching old/new backend template situations. SMARTY_VERSION is no good there.

Re: [2.0] Smartifying the backend

Posted: Thu Mar 22, 2012 12:08 pm
by garvinhicking
Hi!

You mean:

Code: Select all

$tpldir = ( !SMARTY_VERSION ) ? 'tpl' : 'tplnew';
$tfile = dirname(__FILE__) . "/$tpldir/XXX.inc.tpl";
...? I would need an explicit context. This posting is too swamped, I do not have time to read through it all, so a dense description of the problem with some example would allow me to give feedback...

Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Thu Mar 22, 2012 12:43 pm
by Timbalu
Yes, and I already tried to say that in my brainstorm post.... :?

Trying to explain what I tried to say there, won't do it more clear..., I apprehend.... maybe I should learn some more Suhaeli... ;-)

Well, in short...,
we have converted all these PHP-Templates in include/admin to SMARTY-Templates to carry the tpl files in include/admin/tpl.
To fallback, we now need two of them, an oldtpl dir and a newtpl dir. The later for YL's backend conversion to HTML5.
Therefore we need this specific switchKEY, I was talking about. Same in converted functions in some /include/ files and other smartified backend dirs. As also having upgrade or installing situations in this context, this has to be very sensitive, described above.

Or is there a much better fallback method I couldn't think of.... ?

Is that more clear...?

Re: [2.0] Smartifying the backend

Posted: Fri Mar 23, 2012 10:11 am
by garvinhicking
Hi!

Why would we need old HTML DOM layouts? Can't we just convert that one .tpl file to HTML5 syntax and use that one?!

I'm not sure I understand why fallback is even necessary? (I hope I wasn't the one who raised this, but then, I don'r remember - only thing I wanted is to make the s9y installation process work properly with non-writable templates_c directory)

Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Fri Mar 23, 2012 10:56 am
by Timbalu
The non-writable templates_c directory is another building site. It has nothing to do with the fallback question.
garvinhicking wrote:I hope I wasn't the one who raised this, but then, I don'r remember -
... ;-) ...

It would surely be the very best to stay away from any fallback for the backend. But this needs 2k11 delivered as the default template, I assume. Aren't there any other risks (not actually risks, but break possibilities) taken, if we stay away from having old DOM backend fallbacks?

Re: [2.0] Smartifying the backend

Posted: Sat Mar 24, 2012 12:57 pm
by Timbalu
Taking up the installer thread again for a while... Discussion started with:
garvinhicking wrote:IMHO the installer should not depend on smarty for proper installation operation.
If smarty cannot write to templates_c/ for example, the installer would not load up at all without a working smarty environment.
I must come back to this. In fact we have this situation:
  • We do have an error DIRECTORY_WRITE_ERROR, if the Smarty compile_dir fails. Normally this did not stop anything else than smarty init() returning false into the workflow, below 1.7.
  • With Smarty 3 we will now receive an Exception and Stop, everywhere init() does stop at this point. If not done by Serendipity's Error function, this will happen in Smarty, though.
  • This is a change. Yes. But without solving this directory to be writable, Serendipity may be installed, but not usable either, as it is bundled with Smarty at all. So this issue must be solved to run Serendipity properly in all cases!
  • This eval ressource thing wont help us here, in the backends installer file, as it is smarty_init() which fails.
  • Rethinking this, we would now have three possible options:
    • Accept this stop if one of the importent s9y-bigfoots is failing. Even in installing situations.
    • Return to a PHP-Template for the installer, to avoid Smarty stop while installing.
    • Run a non-writable check and error-stop, before even run the installer in serendipity_admin.php.
Id did test this on a vanilla install and set chmod delivered 'templates_c' to be non-writable before install.
Finally I got:

Keine Schreibrechte für Verzeichnis /var/www/test/s9y-20/templates_c/. Bitte korrigieren

== TESTING ERROR MODE ==

Fatal error: Uncaught exception 'ErrorException' with message 'Serendipity error: Keine Schreibrechte für Verzeichnis /var/www/test/s9y-20/templates_c/. Bitte korrigieren' in /var/www/test/s9y-20/include/compat.inc.php:106
And the nice Stack trace: ...

This happend before any installing procedure was done, which is OK for me as thown (quite) nicely, and as you have to solve the non-writable directory in any case.

This leaves me to the remaining question:
What is the difference of the Installer run through, notice its failing for the compile dir to the user and finish, leaving a plain Frontend erroring to the public, until it got fixed by the user ... and on the other hand have a halt and error notice to the adminuser before any public gets involved?

My vote on this is clear. :)

Re: [2.0] Smartifying the backend

Posted: Mon Mar 26, 2012 1:49 pm
by garvinhicking
Hi!

If you install s9y fresh (WITHOUT serendipity_config_local.inc.php present, and you chmod 000 templates_c, then you will see the installer layout, telling you what is not proper. A plain frontend error message IS NOT PRESENTED. That's what I and our users want. Once installed, if something fails, we IMHO don'T need to present the installer, in that case a more simpler error notice should suffice.

IMHO we should change the whole process in 2.0 so that:

1. s9y does NOT fail on a non-writable templates_c directory in NORMAL operation, so Smarty must made to be loadable

2. On installation, s9y utilizes Smarty (in the way above), but installation cannot continue unless templates_c is made writable.

As for the other question about non-2k11 fallbacks. I think it's too much work to maintain a "old DOM"-variant for the backend, so we shouldn't put effort into making that possible. IF at some point we see that 2k11 does something so horribly brutally incompatible to specific backend action, we can get to that point again. Then we could think about creating a serendipity_smarty_init_backend() method, where we could check if a non-2k11 theme is used, and adjust the smarty "template_path" variable to point to a subdirectory....


Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Mon Mar 26, 2012 3:05 pm
by Timbalu
I'm starting to get light confused... :wink:
garvinhicking wrote:1. s9y does NOT fail on a non-writable templates_c directory in NORMAL operation, so Smarty must made to be loadable
That means "disable our trigger_error(DIRECTORY_WRITE_ERROR)" in our s9y_smarty class, to not fail in general, right?
garvinhicking wrote:2. On installation, s9y utilizes Smarty (in the way above), but installation cannot continue unless templates_c is made writable.
That means "put the s9y_smarty class trigger_error(DIRECTORY_WRITE_ERROR) into the installer, to stop installing until solved, right?
garvinhicking wrote:As for the other question about non-2k11 fallbacks. I think it's too much work to maintain a "old DOM"-variant for the backend, so we shouldn't put effort into making that possible. IF at some point we see that 2k11 does something so horribly brutally incompatible to specific backend action, we can get to that point again. Then we could think about creating a serendipity_smarty_init_backend() method, where we could check if a non-2k11 theme is used, and adjust the smarty "template_path" variable to point to a subdirectory....
Well, I did just commit some of these changes figured out with YL - but they are hardcoded, so the second won't work until getting smartified, right?