Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
switching the default layout on the fly
I display one large image on my home page. If the image is in vertical format, I have one layout. If I have a horizontal format image, a different layout should be used. But I don’t see how to do this as long as the main page is always tied to the default layout.
I select the image using a random php script, but php seems to execute after txp parsing, so it wouldn’t help much. Or would it? The layout changes are too complex to be done in CSS alone (at least by me).
I can think of hacks to make this happen, but is there an approved workable way within textpattern to make it happen? I know that there are txp conditional tags, but can they interpret the outcome of a php random process that happens after they are parsed? I wouldn’t think so…
Thanks for any guidance.
dan
Offline
Re: switching the default layout on the fly
but php seems to execute after txp parsing,
Read the FAQ: How do I use PHP Code.
Offline
Re: switching the default layout on the fly
Thanks, Sencer
I missed the <code><txp:php></code> tag. The information is useful, and it opens up some possible hacks.
What I am more interested in is a txp-native way to do what I want to do. Anyone have any insight into tricks or hacks that don’t resort to php to alter the layout and optionally the CSS of a default page on the fly? I’d like to think that a CMS is there to avoid the need for custom coding, and this doesn’t seem like a unique need.
<hr />
Somewhat Peripheral and Esoteric
A bit of testing of the php execution was interesting. I have a <code><txp:php></code> block on my default page that accesses global variables that are defined earlier in the page, and also in an included file. That works well, which is great.
But if I refer to a function in the included file with
<blockquote>
<code>
<txp:php>
echo (myFunction());
<code></txp:php></code>
</code>
</blockquote>
it treats the contents of the outer parentheses as a literal string. Only if I add a conventional <code><?php … ?></code> block inside the txp tag as:
<blockquote>
<code>
<txp:php>
<?php echo (myFunction()); ?>
</txp:php>
</code>
</blockquote>
does it work as expected, echoing the result of the function. But the documentation expressly says not to include the <code><?php … ?></code> container. Hmmm. Am I missing something?
If I access the php variable I defined with a conventional php block like this:
<blockquote>
<code>
<?php echo $myVar; ?>;
</code>
</blockquote>
it works, but if I add a <code><txp:php></code> block after:
<blockquote>
<code>
<?php echo $myVar; ?>;
<txp:php>
$myVar++;
</txp:php>
</code>
</blockquote>
the first statement reflects the action of the later, txp statement. So it seems like textpattern is executing php in the page more than once: the first time an eval() for the <code><txp:php></code> blocks, and the second time for the <code><?php … ?></code> stuff, after the txp parse. But if I add a statement like
<blockquote>
<code>
<txp:php>
echo “<?php global $myVar;
$myVar++; ?>”);
</txp:php>
</code>
</blockquote>
which might be expected to add new php that gets executed after the txp parse, the system dies with
<blockquote>
<code>
Parse error: parse error, unexpected $, expecting ‘,’ or ‘;’ in /path/to/my/site/textpattern/publish/taghandlers.php(1661) : eval()’d code on line 4</code>
</blockquote>
I assume that this is a security feature masquerading as a broken parse, except that it can’t be the presence of <code><?php … ?></code> within the <code><txp:php></code> block, since the call to the function would have produced the same problem if that were the reason. Odd, but maybe someone knows why all this is as it is.
Neither the documentation you pointed to, nor the tag list says anything about order of execution or re-parsing after initial php execution. But this seems to indicate that the system, while functional, is a bit provisional.
What would help is if someone could point out where the internal values that textpattern uses are exposed to php of this sort. Anyone know?
Offline
Re: switching the default layout on the fly
What I am more interested in is a txp-native way to do what I want to do.[…] I’d like to think that a CMS is there to avoid the need for custom coding, and this doesn’t seem like a unique need.
Randomizing html-code and css in a synchronized fashion is not something that is a typical CMS functionality. It’s the perfect thing for a plugin to do. If you expect features like that in the core, I think you will find more suitable CMS that aggregate more and more random functionality with every release.
But if I refer to a function in the included file with it treats the contents of the outer parentheses as a literal string.
Can’t reproduce this behaviour. Can you provide an exact example? Or was that already one? For me it does a regular function call as would be expected.
To your other examples: Don’t mix <?php with txp-style php-tags. It will lead to confusion. That was on eof the main reasons why we wanted to completely take outsupport for <?php, and the only reason we didn’t was to not break backwards-compatibility.
<? is eval()’edonce at the very end after all other tags are completely parsed and the page is about to be sent to the browser.
txp:php is eval()’ed as you would expect it from any other txp-tag. It is handled by the same tag-parser that handles all other tags as well.
Each txp-php tag is eval()’ed “by itself” and not in the global scope, meaning if you want to reference variables you define earlier you have to explicitly make them global.
I assume that this is a security feature masquerading as a broken parse,
You’re interpreting way to much into things. If you take a look at the things in txp-code responsible for eval()ing php-blocks it would take a lot less time than you have sepnt typing up your post. :)
Neither the documentation you pointed to, nor the tag list says anything about order of execution or re-parsing after initial php execution. But this seems to indicate that the system, while functional, is a bit provisional.
<? is not supported, forget all about it.
txp-php works like any other txp-tag. Special things to watch out (scope etc.) for are explained in the FAQ-page. The FAQ explicitly states not to mix the different types of php-tags.
If you feel something is not working as advertising, we need a way to reproduce it. I think you’ve tried to provide that, but I couldn’t reproduce it.
What would help is if someone could point out where the internal values that textpattern uses are exposed to php of this sort. Anyone know?
Have you thought about writing a plugin? There is a mailing-list for plugin developers, I am sure you’ll find help there.
Offline
Pages: 1