eZ Community » Forums » Setup & design » Override paragraph.tpl ?
expandshrink

Override paragraph.tpl ?

Override paragraph.tpl ?

Monday 25 May 2015 3:30:41 pm - 8 replies

I need to override paragraph.tpl (content/datatype/view/ezxmeltags/paragraph.tpl) for a view (line) for one particular class. Problem is that <p></p> breaks intended design.

Is that even possible?

I know how to override paragraph.tpl globally, but as that affects all use of paragraph it is not the solution.

Tuesday 26 May 2015 6:56:16 am

Hello Atle,

Take a look at, https://doc.ez.no/eZ-Publish/Technical-manual/4.x/Reference/Template-override-conditions

Review the section of the page titled, "content/datatype/view/*.tpl".

These template override condition rules (should, to my knowledge) be able to be used to do what you desire (at a class level or combined at a class + attribute_identifier level, for greater level of usage control IE: multiple xmlblock attributes within a class).

I hope this helps!

Cheers,
Heath

Friday 29 May 2015 7:36:29 am

Hello Heath. Sorry for the delay.

I tried to work around the problem like this:

{attribute_view_gui attribute=$node.data_map.intro linebreak="true"}

and the code for paragraph.tpl

{* default linebreak="false" *}
{if eq($linebreak, "true"blunk.gif Emoticon}

    {$content}<br> <br>{elseif eq($linebreak, "false"blunk.gif Emoticon}

 {set $classification = cond( and(is_set( $align ), $align ), concat( $classification, ' text-', $align ), $classification )}

<p{if $classification|trim} class="{$classification|wash}"{/if}> {if eq( $content|trim(), '' )} {else}{$content}{/if} </p>

{else}

<p> Mary had a little child... </p>

{/if}

But it triggers else any what i put in the {attribue_vire_gui... If i chenge the {* default at the top, the if/elseif/else works. So the $linebreak does not get sent to the paragraph.tpl...

Any ideas?

Friday 29 May 2015 10:29:44 am

Hello Atle,

I'm a little disapointed you did not at least try my suggestion and instead replied saying you did something else completely different .. and it did not work (which is trying). I'm short on time but in short your failing to pass your linebreak parameter through the chain of execution (template includes to the paragraph template). I'm not going to try to force what you were trying to do to work (I could but I think it would require a kernel class override which I would *not* ever want to do to exmltag template processing, etc, way to complicated and crazy to maintain) but ultimately I think I found a more flexible and content based solution.

I tested -my- suggestion (which does work) but I was ultimately unhappy with the realization that it was basically content class level control which is fairly inflexible ... without more work to isolate the use case into a separate class which I just think is something I too would avoid. So unhappy with that solution (on it's own) I looked for ways to extend this solution further.

What follows is a little complicated to understand / follow (plus I'm still wiped out and should be sleeping) so bear with me ...

I found that if you create a 'settings/override/content.ini' rule (see following example) to provide a 'specialmeaning' class (option) to the 'paragraph' ezxmltag (clear caches), then edit a folder content object xml block, click on a paragraph (line of text; since we can't see paragraphs (per-say) in ezoe distinctly by default), now this is the tricky part ... move your mouse to the bottom of the ezoe xml block attribute container gui to the ezoe status bar where it displays the 'tag name' of the tag which the current cursor is within at the moment IE: 'paragraph', click the text 'paragraph' (again in the bottom ezoe status bar *not* the ezoe format drop down menu option list), next you will see a pop-in (pop up) dialog box open called, 'Edit <paragraph> tag' which will display a 'class' option list drop down which defaults to a option menu selection to 'None'. Select the 'class' option list drop down menu and change selection to the class option item 'specialmeaning' and click 'Ok' (the dialog will close), then click the button to disable ezoe gui and see the raw ezxml content markup (this is a red X icon in latest version in the ezoe toolbar).

The page will refresh, disable the xml block ezoe gui and you can see that the paragraph tag you added the custom ezxmltag content class 'specialmeaning' to is right there within the ezxml content markup! Now publish your modified content object and reload the page on the user siteaccess site to inspect the output for the 'specialmeaning' class in your <p> tag output html.

Now in your custom paragraph template override (as I suggested and proved works via override.ini settings) you can use custom template code (that you write, to do -what ever it is you require-) within this semi less global template override (ehh class & attribute specific) to test of use of the custom ezxml paragraph tag class 'specialmeaning' within your custom template override and then when used (which is content / content object specific, which is the level of specificity I was honestly looking for when I started giving answers in this thread). 

Then use conditional code to do the custom template code (tpl, html, css, etc, whatever) you need for your use case.

This provides more then enough flexibility for almost any possible use case and once you set up the implementation the content editor (anyone, or just you) can trigger it by making admin content modifications (instead of maintaining content specific static code, which is messy, harder to maintain and support and very inflexible).

Here is an example of what I played with in file, 'extension/userSiteAccessExtension/design/userSiteAccessDesign/override/templates/content/datatype/view/ezxmltags/paragraph_custom.tpl'.

{set $classification = cond( and(is_set( $align ), $align ), concat( $classification, ' text-', $align ), $classification )}
 
<p{if $classification|trim} class="{$classification|wash}"{/if}>
 
{if eq( $content|trim(), '' )}&nbsp;{else}{$content}{/if}
 
{if $classification|eq('specialmeaning')}<hr /><hr />THIS IS A SUCCESSFUL TEST! You Win! Now drink some orange juice and look to the sky ... <hr /><hr />{/if}
 
</p>

Oh and before I forget here is an example of my override.ini rule settings for this template override from file, 'settings/siteaccess/userSiteAccessName/override.ini.append.php'.

[paragraph_custom]
Source=content/datatype/view/ezxmltags/paragraph.tpl
MatchFile=content/datatype/view/ezxmltags/paragraph_custom.tpl
Subdir=templates
Match[class_identifier]=folder
Match[attribute_identifier]=description

Oh and even more to share before I forget. Here is an example of my content.ini rule settings for this template override from file, 'settings/override/content.ini.append.php'. Please note that these settings should be global not siteaccess specific since they are only content tag options not definitions and because the solution requires the same settings be available in more than one siteaccess (re: admin and user siteaccess)

[paragraph]
AvailableClasses[]=specialmeaning

I recently was re-taught this paragraph class change trick by a friend earlier this year big-smile.gif Emoticon Ahh the things we forget we learned over the years of implementing eZ. LOL

Note: Please remember that template overrides defined within override.ini rules must live in the override/templates directory subtree (in general). I ran into this problem at 2am this morning still half asleep implementing my suggestion and testing it.

Again apologies for my run on sentence, late reply .. I'm not awake big-smile.gif Emoticon and on my way back to bed but wanted to reply when I was woken up in the middle of the night when I saw your reply.

Best wishes Atel, I hope you can understand my examples and why my idea is a little more 'flexible' than you idea (re: content class, content object, content attribute and <paragraph> tag level control) and can implement this tested solution on your own.

I hope this helps!

Cheers,
Heath

Modified on Friday 29 May 2015 10:55:00 am by // Heath

Saturday 30 May 2015 8:05:23 am

Hey Heath.

I did not ignore your suggestion, I just started poking around forgetting to check the forum, so I hope I did not offend you.

Your solution is long, I havent read it thorough yet, and I need som time to try it, but I will try it and report back happy.gif Emoticon

--- update ---

So, just like you I could not just leave this but had to test immideately, once in mind it would not go away blunk.gif Emoticon (wife is now a bit angry, hehe, I was supposed to vacuum)

I tried the solution, and of corse it worked as you intended happy.gif Emoticon

There is a coulpe of problems with your solution.

First; we would have to trust the editors/users to acually do the step in the ezoe - well, we dont. Based on experience that would fubar our design, and trust me; they never learn. Not even when seeing the actual pages with their writings themselves.

Second; the reason why I seeked the parameter soultion based on template is that we have several overrides to display content of one class (in line view) several ways. Eg our full_node_122.tpl (where we will have both the <p> and the <br>blunk.gif Emoticon has one design (our front page), full_node 182.tpl (which is the sub sections frontpage where we will have only <br>blunk.gif Emoticon, and full_folder.tpl which is the vanilla (<p>blunk.gif Emoticon. And so on. There are several other situations (colors eg, avoiding CSS), but this simple example should do.

When I say sub section, it is not an section i eZ, just a folder in the content tree. A node.

I need this to be implemented on a per override template basis, I cannot trust the users. I dont have faith in humans based on experience blunk.gif Emoticon That's why I tried and modified a bit (to not use deprecated syntax) this "solution":

http://share.ez.no/forums/suggest...n-an-ezxmltext-datatype#comment52530

Well, obvieousely it does not work.,, So, that's where I stand atm...

Was that clearifying? Im sorry I did not explain better in the former posts, sometimes I cut corners taking it for given that everybody gets what I mean (witout actually saying what I mean).

Modified on Saturday 30 May 2015 8:55:42 am by Atle Enersen

Saturday 30 May 2015 12:59:07 pm

Hello Atle,

Thanks for the prompt reply. I'm not really that upset blunk.gif Emoticon 

Oh and sorry for getting you into troubles with the family .. hehehe. I get into trouble like that myself at times big-smile.gif Emoticon

Thank you for sharing more about the potential use case requirements your working with. I guessed but was not certain. You sharing more information really helps!

I completely understand not being able to trust editors! So enough said on that subject big-smile.gif Emoticon

My initial reaction is what about testing for absence of a class? But I am fairly certain even that is not good enough (IE: not flexible or trust worthy enough. Re: Editors & Input Classes)

I'm going to look deeper at another more complicated (to implement; not use) solution which should be simpler to use overall. Give me a little more time this afternoon to do this if you can.

Now go vacuum big-smile.gif Emoticon I think I will do the same this weekend, I sure need to at the very least happy.gif Emoticon

I'll reply as soon as I can with a less time consuming (I hope) to process reply / solution.

Cheers,
Heath

Sunday 31 May 2015 5:04:28 pm

Hello Atle,

I have found and tested the solution I wanted to suggest in my last reply (and really even from the start but I hesitate to jump to first recommending kernel class overrides, even when I knew from lots of past forum history and development that what you want is basically not supported very well by default).

I did a *lot* of research and testing in the last two days to find, create and test the following solution.

During my testing I found that for the most part ezxmltext template overrides are supported by override.ini Match rule conditions 'attribute_identifier' only or global override (used everywhere). This finding was different than what I thought / mentioned previously in this thread.

This finding was disappointing but I want to point something out. A unique class attribute identifier could be used for class level and attribute identifier level control of a template override. It might be enough for some folks who think creatively but do not want to use a kernel override (see next section).

That said it's not very flexible and in the end I was left wanting much more control / Match conditions for this use case ... I mean why not provide them if they are possible? Well I found a solution ..

Edit: I published a git repo containing the result of most of the above steps described which should make this solution simpler. https://github.com/brookinsconsulting/bcxmltemplateoverrideconditions

Note: This solution does not depend on anything in the previous (above) suggestions.

If you create a kernel class override extension with the class file, 'kernel/classes/datatypes/ezxmltext/ezxmloutputhandler.php', patch it with the following patch, enable config.php and enable kernel overrides within config.php, generate kernel override autoloads and edit your override.ini.append.php rules you can use all the new Match conditions / rules provided by the patch (quite a lot more).

https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/classes/datatypes/ezxmltext/ezxmloutputhandler.php

Additional override.ini template override match conditions for ezxmltext templates Patch by Brookins Consulting: https://gist.github.com/brookinsconsulting/77df6f70fedf7755628b

You would basically create an extension + class directory and prepare the solution like this:

define( 'EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE', true );

Then run the following command to regenerate kernel override autoloads (this is the only command required, you do not need to regenerate extension autoloads as well):

  • php -d memory_limit=-1 ./bin/php/ezpgenerateautoloads.php --kernel-override;
  • Then clear all caches!

Then edit your override.ini rules to use the new match conditions require. Only use the ones you require. BTW, due to limitations at the time of this patch creation we used main_node instead of the actual current node since I did not know of a way to get the actual node used when rendering the object (possibly unknowable in my experience) therefore using the 'object' match condition is a little more accurate than 'node' match condition. Now it's time to reload the page to test the new solution for potential concerns.

Just to be clear I do not have any initial concerns supporting this solution. It's fairly clean, requires only one kernel override of a legacy class that is very stable and not subject to much change (if at all) per release (which is important for maintainability), the class has not needed a bugfix since late 2012 and the entire solution would be completely extension based (which I always insist upon, by default).

https://github.com/ezsystems/ezpublish-legacy/commits/master/kernel/classes/datatypes/ezxmltext/ezxmloutputhandler.php

I would support the solution I just described it if a customer really wanted it, willing to fund the development. I do not think this patch would ever be acceptable / accepted into the default legacy release via PR because of the complications / risks it might possibly introduce / BC.

Please let us know how this solution works for you! If you have any questions or problems please feel free to let me know.

I really hope this helps! Have an excellent weekend!

Cheers,
Heath

Modified on Sunday 31 May 2015 5:20:31 pm by // Heath

Tuesday 09 June 2015 8:04:27 am

Hello Atle,

I was wondering if my new extension solution was helpful to in solving your problem?

Cheers,
Heath

Friday 26 June 2015 10:53:56 am

Sorry for the delay, Heath. Some other urgent matters ate my time, but I hope I will get the time to look into it now in the summer snooze of july happy.gif Emoticon

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from