New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpret static page html as template #226

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@mirkobeine
Copy link
Contributor

mirkobeine commented Jan 20, 2015

The given change will fetch the html content of a static page, processing it as a regular smarty template instead of directly assigning the html content to the view. Therefore, any smarty function (e.g., {url}) can be used in a static content site.
For example, this enables a power user to easily create links between static pages.

Mirko Beine
Interpret static page html as template
The given change will fetch the html content of a static page, processing it as a regular smarty template instead of directly assigning the html content to the view. Therefore, any smarty function (e.g., {url}) can be used in a static content site.
For example, this enables a power user to easily create links between static pages.
@bcremer

This comment has been minimized.

Copy link
Contributor

bcremer commented Jan 21, 2015

Thank you @mirkobeine, that one looks interesting.

But this might break compatibility for existing customers that might already have unescaped { in their pages.

Any ideas how to work around that?

@mirkobeine

This comment has been minimized.

Copy link
Contributor Author

mirkobeine commented Jan 21, 2015

You're absolutely right. Would it be sufficient to add an additional flag in the backend:

  • interpret as smarty template

That way, any customer could decide for himself whether he want's the content interpreted or not.

@bcremer

This comment has been minimized.

Copy link
Contributor

bcremer commented Jan 21, 2015

Sounds great. Can you update your pull request accordingly?

@mirkobeine

This comment has been minimized.

Copy link
Contributor Author

mirkobeine commented Jan 21, 2015

OK. I'll probably be able to update the PR during the upcoming weekend.

@dnoegel

This comment has been minimized.

Copy link
Contributor

dnoegel commented Jan 22, 2015

We could also consider to have a migration file which

a) replaces {foo} with {literal}{foo}{/literal} - downside: RegEx required, will double your problems by definition
b) replaces any page content X with {literal}X{/literal} - this would even be possible with a quite simple delta.

I know, both is not, what one really WANTS to do - but adding options over and over again is also not the real deal, isn't it?

@bcremer

This comment has been minimized.

Copy link
Contributor

bcremer commented Jan 22, 2015

@dnoegel good thought 👍
I am in favour of b).

It's just a simple migration file, no additional changes in the database-structure or changes to the backend module is required.

@mirkobeine Any opinions from your side? If you could provide that migration file we can merge this PR for SW 4.3.3.

@mirkobeine

This comment has been minimized.

Copy link
Contributor Author

mirkobeine commented Jan 23, 2015

Just to be clear: am I right in thinking that with migration, you suggest a db migration file that will simply wrap the static content in a '{literal}'-Block?

@bcremer

This comment has been minimized.

Copy link
Contributor

bcremer commented Jan 23, 2015

@mirkobeine sorry for being unclear. Yes, create a new migration file inside _sql/migrations that wrappes existing sites with the {literal} block using a simple UPDATE statement.

You can test the migrations using the build/ApplyDeltas.php script or rebuild the whole installation running ant build-unit inside the build directory.

@bcremer

This comment has been minimized.

Copy link
Contributor

bcremer commented Mar 10, 2015

@mirkobeine Any news on this PR?

@mirkobeine

This comment has been minimized.

Copy link
Contributor Author

mirkobeine commented Mar 10, 2015

Damn, was too busy since - I'try to finish this one by tomorrow.

@hlohaus

This comment has been minimized.

Copy link
Contributor

hlohaus commented Mar 10, 2015

Hi,
man kann jetzt schon mit einem Trick Smarty in den Shopseiten verwenden.

Dazu muss man nur folgende Einstellungen vornehmen:

Tpl. Variable 1: sContent
Tpl. Pfad 1: string:{$sContent|replace:'[script]':'IhrScript'}

Beispiel: http://i.imgur.com/WENbuFX.png

Oder:

Tpl. Variable 1: sContent
Tpl. Pfad 1: string:{include file="string:{$sContent}"}

Heiner

@hlohaus hlohaus closed this Mar 10, 2015

@hlohaus hlohaus reopened this Mar 10, 2015

@xetys

This comment has been minimized.

Copy link

xetys commented Mar 10, 2015

I should warn you of an issue with this PR. I actually did the same using a Plugin and a Replace hook "Shopware_Controllers_Frontend_Custom::indexAction::replace" with exactly the same changes from this PR.....and it is workin fine, but:

when you are trying to use the "Action Plugin", so you should be able to use "{action module=widgets...}" inside pages, you just get a big white blank page.

I was going deep inside debugger to find the error, assuming an error with the output buffer.
But even after setting disableOutputBuffering to true via config is still giving me a blank page....but only when a page contains a call of action plugin

any ideas with it?

@xetys

This comment has been minimized.

Copy link

xetys commented Mar 10, 2015

This occurs also with the trick by @hlohaus

@hlohaus

This comment has been minimized.

Copy link
Contributor

hlohaus commented Mar 11, 2015

You mean this:?
{* Article content *}
{block name='frontend_custom_article_content'}
{include file="string:{$sContent}"}
{/block}
Result:
magic

@xetys

This comment has been minimized.

Copy link

xetys commented Mar 11, 2015

no, i mean this:

{action module=widgets controller=listing action=top_seller sCategory=someId}

you could also define any custom widget via plugin, to show some additional content....but then you get a blank page...

the action plugin only works when it is callen directly in template, not in that workaround over Shopware sites

@hlohaus

This comment has been minimized.

Copy link
Contributor

hlohaus commented Mar 11, 2015

yes, i mean this too. But i have other working fix:
Change in:
templates/_emotion/frontend/custom/index.tpl
this:
{$sContent}
to this:
{include file="string:{$sContent}"}

This is bad:
$this->View()->fetch()
because is not working with ESI-Tags / the httpCache-Plugin.

@xetys

This comment has been minimized.

Copy link

xetys commented Mar 11, 2015

yes! that was it :D thanks!

@shopwareBot shopwareBot closed this Jun 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment