print.css - needing pointers on how to use

[Oliver Georgi]

implemented. If you want to use it right now change content.func.inc.php

around line 320 enhance it like this:

Code: Select all

// -------------------------------------------------------------

$content['list_mode'] = true; //SET LIST MODE ALWAYS TRUE!

if($aktion[4]==1 && $aktion[1]) {

	// render page based on article
	include_once(PHPWCMS_ROOT."/include/inc_front/content.article.inc.php");
	$content['list_mode'] = false; //OK, NO LIST MODE article detail will be rendered

} elseif(!empty($content['struct'][$content['cat_id']]['acat_pagetitle'])) {

Then add at the end - direct before closing ?>

Code: Select all

// check layout for list mode sections or detail view
if(strpos($content['all'], '_LIST_MODE')) {
	$content['all'] = replace_tmpl_section( ($content['list_mode'] ? 'ELSE_LIST_MODE' : 'IF_LIST_MODE') , $content['all']);
	$content['all'] = str_replace(array('<!--ELSE_LIST_MODE_START//-->', '<!--ELSE_LIST_MODE_END//-->', '<!--IF_LIST_MODE_START//-->', '<!--IF_LIST_MODE_END//-->'), '', $content['all']);
}

That's all.

Oliver

[jsw_nz]

Hi Oliver,

Thanks for that

Made the changes and this is what I found out.
The code:

Code: Select all

<!--IF_LIST_MODE_START//-->
--> will be shown when in article listing mode
--> everything wrapped in ELSE_LIST_MODE will be deleted
<!--IF_LIST_MODE_END//-->

<!--ELSE_LIST_MODE_START//-->
--> will be shown when in article detail mode
--> everything wrapped in IF_LIST_MODE will be deleted
<!--ELSE_LIST_MODE_END//-->

is pretty flexible - it can run in articles, custom article templates and even in defaults (template/inc_default/ directory). So this is ideal for pasting these snippets wherever they need to be to adjust output.

Having said that - I notice that for more global operation - (ie using custom option in pagelayout (from template main block) what happens is that essential duplicate rendering take place - after which one of the '2' renderings gets stripped out. This is OK in of itself - but found errors thrown if content had special {REP_TAGS} (double call to function?)

My hack (and this is what it is) suits better - that is an interface where two separate layout schemes can be viewed in totality - no confusion having to read through code an look for <!--IF_LIST_MODE_START//-->, etc tags.
Here is the screen shot of the backend of this scheme...



this enables me to see the logical structure of the layout and since it is grabbed before page rendering - there is no double rendering and no duplicate call to {REP_TAGS} - so just putting this out there as an idea from an appreciative user of wcms. Might there be a way to incorporate the automatic creation of these two options (list | full) when custom option for pagelayout is selected?

Additionally the thought crossed my mind - with regards to other layout optiions (tables or wcms div) to have something like this:



so basically option to access separate templates - i like the idea - but I know that your opinion and strategy is spot on......

so would defer this to your better judgement
- interesting idea however, methinks

All the best
John

[Oliver Georgi]

...it is no problem to change rendering position ...

The only thing that has to be done (if using my change right now) is moving

Code: Select all

// check layout for list mode sections or detail view
if(strpos($content['all'], '_LIST_MODE')) {
	$content['all'] = replace_tmpl_section( ($content['list_mode'] ? 'ELSE_LIST_MODE' : 'IF_LIST_MODE') , $content['all']);
	$content['all'] = str_replace(array('<!--ELSE_LIST_MODE_START//-->', '<!--ELSE_LIST_MODE_END//-->', '<!--IF_LIST_MODE_START//-->', '<!--IF_LIST_MODE_END//-->'), '', $content['all']);
}

from bottom of the page (end of rendering process) after the position where all blocks including main layout are merged to final template. And this happens around line 477 - so put it before the line

Code: Select all

// {SHOW_CONTENT:MODE,id[,id[,...]]}

Then there will be no double calls anymore because all "double" are replaced before global rendering starts.

Your solution in most cases will result in more work. Because in general there will be small differences between article and listing view.

For complexer situations I really recommend using frontend_render scripts - and remember the simple value

Code: Select all

$content['list_mode']

which has two possible states: TRUE or FALSE and can be used to do custom processings...

And additional to frontend_render there is a really easy way to inject HTML <head> by custom code using:

Code: Select all

$block["htmlhead"]

- this is a global array. So any new line or code section in <head> can be used like this:

Code: Select all

$block["htmlhead"][] = '  <script src="'.TEMPLATE_PATH.'inc_js/mycustom.js" type="text/javascript"></script>';

or if you need have to combine multiple string sections there:

Code: Select all

$block["htmlhead"]['myjs']  = '  <script type="text/javascript" language="javascript">'.LF.SCRIPT_CDATA_START.LF;
$block["htmlhead"]['myjs'] .= '    loadMyJSFuntion();'.LF;
$block["htmlhead"]['myjs'] .= SCRIPT_CDATA_END.LF.'  </style>';

Kinda like functionality is available for CSS (above solution can be used too to enhance CSS):

Code: Select all

$block['css']['additional_css'] = 'mycss/special.css';

This will result in loading your custom CSS from directory

Code: Select all

template/inc_css/mycss/

using @import.

Hehe - and again: I recommend using UFO which is part of distribution.



Oliver

[jsw_nz]

wow

- thanks very much for your 'detailed' response
- will need to study (as students often do....)

I think the whole design principle is design flexibility
which phpWcms is a clear example (and leader)

on another note..
I will be arranging sending a further contrib (paypal)
in the next 48.......

big thanks
and appreciation to you

cheers
john

[jsw_nz]

OK - Thanks Oli

Everything works now
- and thanks for the other pointers - all makes sense

Regarding using ufo as the default flash wrapper in core:

My only concern is the lack of support to use phpWcms {REP_TAGS} to populate FlashVars - since these parameters are send via javacript in head. Are you suggesting adding these via $block["htmlhead"]:

Code: Select all

$block["htmlhead"][] = '  <script type="text/javascript">
// <![CDATA[
var FO = {movie:"flash/vers001_header.swf", width:"100%", height:"300", majorversion:"8", build:"0", xi:"true", flashvars:"pagetitle={CATEGORYTITLE}&loadimage={GET_IMAGE}" };
UFO.create(FO, "ufoDemo");
// ]]>
</script>'

I did troubleshoot swfObject and found that adding the defer parameter in the inline script fixes the bugs I was experiencing

Code: Select all

<script type="text/javascript" defer="defer">

- not sure if this solves other issues you mentioned. All I wanted to share is the need to handle FlashVars in an easy and straightforwrad way - this might be easy in templates but harder when using MM contentpart. Guessing you have a smart idea or two in mind

cheers - all best

[Oliver Georgi]

in german we would say "doppelt-gemoppelt" regarding how to send flash vars. If you use custom replacement tags - it's more easy to write it like this:

Code: Select all

...flashvars:"pagetitle='.mytagfunction().'...

And do not use xi: true -> will not work for a lot of computers having older flash in IE.

Oliver

[jsw_nz]

Still unclear - sorry - this code - which works great for ufo in head is diferent when using the additional $block["htmlhead"][]:

Code: Select all

$block["htmlhead"][] = '  <script type="text/javascript">
// <![CDATA[
var FO = {movie:"flash/vers001_header.swf", width:"100%", height:"300", majorversion:"8", build:"0", xi:"true", flashvars:"pagetitle={CATEGORYTITLE}&loadimage={GET_IMAGE}" };
UFO.create(FO, "ufoDemo");
// ]]>
</script>'

is hard to work with - content.funct.inc.php is throwing an error (string function) when using it.

{CATEGORYTITLE}
{GET_IMAGE}
are wcms generated values - using rep_tags

so basically some confusion on where to place code in template such that it gets parsed and rep_tags get substituted and finally placed in head of final page - pointer really appreciated.

[Oliver Georgi]

you replacement tag will not work because all frontend_render is processed after all main rendering is done. But there is no need to use it because you can run any PHP function - same as when RT is rendered.

But you are free to use whatever you like (SWFobject).

The both RTs you are using are not part of core code...

Oliver

[jsw_nz]

Thanks Oli

Guessing I will go with swfObject atm (and take my chances)
since the ufo script is not as straightforward
- embedding functions which address rep_tag functionality

- although will try to stretch my mind into php function as you mentioned...
since I am a student and not a master - wee bit difficult

I really appreciate your answering this ? atm 8:00am Berlin time...

i recognize your tireless devotion