Page 4 of 12

Re: [2.0] Smartifying the backend

Posted: Mon Mar 12, 2012 4:39 pm
by garvinhicking
Hi!

Hm, that's strange, I do think there must be a way to use Smarty in a non-writable environment (even when it takes longer, technically this should be possible...?)
As far as I read, smarty needs such a folder. But one can set any folder, it doesn't have to be templates_c/ (and according to the docs, /templates_c/ like we use it - under the webserver-root - is a bad idea). Shouldn't it always be possible to create a temp-directory? We could use that.
No, on installing we cannot deduce a temporary failsafe storage anywhere....

Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Mon Mar 12, 2012 5:00 pm
by onli
garvinhicking wrote: Hm, that's strange, I do think there must be a way to use Smarty in a non-writable environment (even when it takes longer, technically this should be possible...?)
I didn't research this extensively, but if smarty is simply a php-script which takes a tpl and converts it to php, and that php is afterwards executed, i am not sure it is technically that easily possible to pipe everything in ram from one interpreter to the other.

Or maybe it is so common it is not documented, at least not for me to find.
garvinhicking wrote:No, on installing we cannot deduce a temporary failsafe storage anywhere....
http://www.php.net/manual/en/function.s ... mp-dir.php really don't seem to be reliable, according to the comments. That's a pity.

Re: [2.0] Smartifying the backend

Posted: Tue Mar 13, 2012 1:32 pm
by garvinhicking
Hi!

If Smarty compiles a file to $file and saves that as /temporaryfile, and then includes that file - the same could be achieved by "eval($file)", I think...so technically it should be possible, and one of the few places where eval is not evil ;)

Ian, would you like to pester Rodney Rehm with that? :)

Regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Sat Mar 17, 2012 1:08 pm
by yellowled
I already notified Timbalu via email, but he seems to be AWOL. I busted my current 2.0 dev blog, but I can't set up a new one since the current 2.0 branch is uninstallable.
Fatal error: Call to undefined function serendipity_smarty_init() in
/var/www/backend/include/admin/installer.inc.php on line 379
So I can't really work on the backend templates unless this is fixed. Timbalu already made some changes to installer.inc.php and functions_installer.inc.php which may or may not be in 2.0 already. I have a local copy of those files, but the installation doesn't work with them, either.

YL

Re: [2.0] Smartifying the backend

Posted: Sat Mar 17, 2012 3:36 pm
by onli
That indeed wasn't working. I commited a fix. Make sure to use the expert installation and check the URL-Setting, the default-setting are probaby wrong.

Re: [2.0] Smartifying the backend

Posted: Sat Mar 17, 2012 9:46 pm
by yellowled
Problem solved. Thank you. :)

YL

Re: [2.0] Smartifying the backend

Posted: Sun Mar 18, 2012 12:31 pm
by Timbalu
garvinhicking wrote:Ian, would you like to pester Rodney Rehm with that? :)
No! I would not like to be the one for pestering issues..! :wink:

Eval is a performance buster, a security issue and not being used any more. There is a new eval resource which still provides the old behaviour. We could use

Code: Select all

try {
  $smarty->fetch('eval:'. $templateString);
  // everything is fine…
} catch(SmartyException $e) {
  // error occured
}
or

Code: Select all

// eval a string template and do not store compiled code
$smarty->display('eval:'.$string);

// display string template and store compiled code
$smarty->display('string:'.$string);
On the other hand..., PHP 5.1 introduced two new streams, php://memory and php://temp. The first will write everything to memory. But this needs php.ini allowed memory size to have enough RAM available. That would be nice to have here, but it seems mkdir() and other functions being used in the Smarty_Internal_Write_File class are not supported by these streams yet.

Rodney once wrote to this kind of problem:

Code: Select all

A very simple solution to your problem would be to extend the internal file resource and simply make it recompiling:

Code:
require_once '…/Smarty.class.php';

class EvaledFileResource extends Smarty_Internal_Resource_File {
    public function populate(Smarty_Template_Source $source, Smarty_Internal_Template $_template=null) {
        parent::populate($source, $_template);
        $source->recompiled = true;
    }
}

$smarty = new Smarty();
$smarty
    ->setTemplateDir('./templates')
    ->registerResource('file', new EvaledFileResource());

$smarty
    ->assign('foo', 'hello world')
    ->display('test.tpl');
So what about these ones, Garvin?

But as I said already, I am going to have a look on this, as this is the installer procedure only and as soon the prototype is ready. For me - at the moment - it seems much simpler, more robust, easier and flexible to just use a raw PHP template in this special case instead. It could reside in the tpl dir too, look nearly the same as the smarty one and would save a lot of energy working around problems and performance issues.

@YL
I am a peaceful man. No military terminology is needed to declare that I was off for a few days, gladly. :) I even remember to have said and left that somewhere... but good that Malte solved your problem!

Re: [2.0] Smartifying the backend

Posted: Mon Mar 19, 2012 12:19 pm
by garvinhicking
Hi!

That eval-resource kind sounds good! Yes, please take a look at it if you like, I'd appreciate that a lot.

I think the ideal solution would be for us to use smarty as usual in the installer procedure, it simply must not choke on a non-writable or missing templates_c directory.
@YL
I am a peaceful man. No military terminology is needed to declare that I was off for a few days, gladly. :) I even remember to have said and left that somewhere... but good that Malte solved your problem!
Hehe ;) Funny thing is that "AWOL" is nearly as long as "away", which describes the same situation in a kinder way ;-)

Best regards,
Garvin

Re: [2.0] Smartifying the backend

Posted: Mon Mar 19, 2012 3:25 pm
by yellowled
garvinhicking wrote:
@YL
I am a peaceful man. No military terminology is needed to declare that I was off for a few days, gladly. :) I even remember to have said and left that somewhere... but good that Malte solved your problem!
Hehe ;) Funny thing is that "AWOL" is nearly as long as "away", which describes the same situation in a kinder way ;-)
Although it does indeed stem from a military context, it is used in colloquial (American) English for non-military purposes these days. Same for MIA, BTW. I most definitely did not think anyone could take offense from this. :)

YL

Re: [2.0] Smartifying the backend

Posted: Mon Mar 19, 2012 4:30 pm
by garvinhicking
As long as we have no KIA, all is fine. :-)

Re: [2.0] Smartifying the backend

Posted: Mon Mar 19, 2012 5:13 pm
by Timbalu
garvinhicking wrote:As long as we have no KIA, all is fine. :-)
Very clever, Garvin! MTFBWY :wink:
We do not want to loose anyone or have another one to KIA! (*[3]) :lol:
* http://www.acronymfinder.com/KIA.html

Re: [2.0] Smartifying the backend

Posted: Mon Mar 19, 2012 6:04 pm
by yellowled
Timbalu wrote:We do not want to loose anyone or have another one to KIA!
See, that one I didn't know. I thought you were talking about Korean cars. :mrgreen:

YL

Re: [2.0] Smartifying the backend

Posted: Tue Mar 20, 2012 5:46 pm
by Timbalu
Back to work...
I just fixed entries.inc.(tpl/php) and templates.inc.tpl. Please see git notes, YL! NFA, hopefully! ;-)

Re: [2.0] Smartifying the backend

Posted: Tue Mar 20, 2012 6:55 pm
by yellowled
Timbalu wrote:I just fixed entries.inc.(tpl/php) and templates.inc.tpl.
Ouch, that will need some fiddleing to "backport" those to my versions of those files. Nevermind.

Would you mind checking in those changes you emailed me earlier to installer.inc.php and functions_installer.inc.php? That would make it a bit easier for me. Beware, Malte made some changes to installer.inc.php which already are in the 2.0 branch. The .tpl files I can handle myself.

YL

Re: [2.0] Smartifying the backend

Posted: Tue Mar 20, 2012 7:40 pm
by Timbalu
yellowled wrote:Ouch, that will need some fiddleing to "backport" those to my versions of those files. Nevermind.
Not really. I didn't touch html code. Just corrected some bug.
yellowled wrote:Would you mind checking in those changes you emailed me earlier to installer.inc.php and functions_installer.inc.php? That would make it a bit easier for me. Beware, Malte made some changes to installer.inc.php which already are in the 2.0 branch. The .tpl files I can handle myself.
I don't get what you are talking about. Which changes earlier...?
What we did, was smuggeling new html code to two internal functions in functions_installer.inc.php. I did not upload that one to GIT, as we have to check the fallback situation first, in case someone uses the current backend... but what did we do with installer.inc.php? I can't remember...