Forum Activity

Forum feed

How are theme variables supposed to work?  Top

  • I don't know if it's a bug, though I suspect it might be. If you add theme variables through the admin interface after having made the variables.ini file writable, new variables overwrite older variables. I think the problem (if it is a bug) lies in how the existing variables are being read into a variable. I made a quick change to the code of pnadmin.php to print_r $variables before assigning it to the template and the existing variables exist in the top level of the array while all new variables get added to the array key "variables". See below (testing is a variable defined in a previous session and the rest are variables set during the current session):

    Code

    array
    (
        [testing] => thisandthat
        [variables] => array
            (
                [anothertest] => blahblahblah
                [eatmy] => shorts
                [flick] => flack
            )

        [anothertest] => array
            (
                [editable] => 1
                [type] => text
            )

        [eatmy] => array
            (
                [editable] => 1
                [type] => text
            )

        [flick] => array
            (
                [editable] => 1
                [type] => text
            )

    )


    It also appears that there is supposed to be some mechanism for assigning a variable type and an "editable" attribute, though neither appear in the HTML form. Is this module just not complete? If that's the case, if someone would let me know what it's supposed to do, I'd be happy to finish it. I just don't want to fix anything for myself that will end up being fundamentally different from what you guys have in mind.

    Thanks in advance.
  • Theme vars can be editable and with different types.
    That's managed by the Theme module, with the 'editable', 'type', 'value', 'output' fields.
    You can have a theme var of 'type'='select' (you define it in the themevariables.ini file).
    Then, when you edit the variable value in the Theme Admin Panel.
    it will show you a SelectList with the (comma separated) values defined for the variable.

    Your themes directory is writable, and you are going to YOURSITE.TLD/?module=Theme&type=admin&func=variables&themename=YOURTHEME
    You should be able to just add a new variable or change a variable name or value.

    An example of the themevariables.ini:

    Code

    [variables]
    indexcol = 1
    lcolwidth = 155
    rcolwidth = 170
    lmarwidth = 25
    rmarwidth = 10
     =

    [indexcol]
    editable = 1
    type = text

    [lcolwidth]
    editable = 1

    type = text

    [rcolwidth]
    editable = 1

    type = text

    [lmarwidth]
    editable = 1

    type = text

    [rmarwidth]
    editable = 1

    type = text

    [topmarwidth]
    editable = 1

    type = text


    If you want a more indepth explanation, you may have to wait for Mark.

    --
    David Pahl
    Zikula Support Team
  • Essentially the way it works currently is that the theme module will read the contents f the variables section of themevariables.ini and assign them to all page templates. The rest of the ini file is purely for display of that theme variable in the admin interface.

    Ammodump has posted a sample ini file. In this sample the variables indexcol, lcolwidth, rcolwidth, lmarwidth and rmarwidth will exist in each of the page templates. Then each of the variables will be available for the user to change in the admin interface> For example the indexcol variable will display as an editable text field.

    Currently the admin interface doesn't allow for control of the display of theme variables but this is planned for a future version.

    -Mark

    --
    Visit My homepage and Zikula themes.
  • Last night i've played again with the Theme vars.
    For me, theme vars controls many things of your theme if you want, and are usable by the Theme, so i don't understand the problem.:

    Quote

    I think the problem (if it is a bug) lies in how the existing variables are being read into a variable


    In the 'BlankTheme', i need to make easy to select the theme-vars default values.
    The possible values are limited, so i can make a SELECT list.


    Here's an example of two theme-vars definitions (themevariables.ini):

    Code

    [variables]
    template = grid
    layout   = crl

    [template]
    type   = select
    values = 2col,3col,grid
    output = 2 columns,3 columns,grid

    [layout]

    type   = select
    values = c,lc,cr,lcr
    output = center,left-center,center-right,left-center-right


    So, when i go to edit the Theme Variables in the Admin Panel, it shows me a SELECT list, with the output text options, and the values defined for each one.
    I guess it's intuitive that if i add a new variable, and i desire to make it "private" (non-editable), i can have a definition like:

    Code

    [variables]
    privatevar = myNonEditableValue

    [privatevar]

    editable = 0

    Now 'privatevar' can't be editable from the Theme Admin Panel.

    So, what's your point?
    what do you want to do with Theme vars?
    or what's the conflict? a Theme var is overriding a module-assigned var?
    you don't want to have the variables in all the templates just in some sections?

    see ya! icon_wink



    edited by: nestormateo, Feb 02, 2008 - 04:38 PM

    --
    - Mateo T. -
    Mis principios... son mis fines
  • I pretty much understand how the theme variables work. That's not the issue. I guess what I'm getting at is that the way admin interface handles them isn't intuitive (or it's broken). Let's say I have a dozen theme variables defined in my ini file and then I decide that I want to add a couple more. My original thought was that this was what the Variables tab in the Edit Theme area was for. So, I go in there and I add a new theme variable or two. Problem is that when those are written to the ini file, they replace the existing ones instead of being added to them.

    I think the way it's written, it's supposed to append new variables instead of overwriting the old ones. I also think that it was meant to take all existing variables and place them in the form for editing. But it appears that because the new variables are stored in an array within the top level $variables array instead of inside the top level array itself (the way existing variables are stored) that the fields that would allow for editing existing variables isn't generated.

    Anyway, I've taken a little more time to look at the code and I think I know what it was supposed to do, so I'm going to fix it to do that for my own purposes.

    Thanks for your help, guys.
  • Seems buggy to me... is this normal?

    Adding one var generates the variables section with that var:

    Code

    [variables]
    this = that


    Adding another var generates the second entry as well as the section named for the previous var:

    Code

    [variables]
    this = that
    those = these

    [this]
    editable = 1

    type = text


    Adding a third item has a similar effect:

    Code

    [variables]
    this = that
    those = these
    thus = is

    [this]
    editable = 1
    type = text

    [those]
    editable = 1

    type = text


    All seems good other than I'd expect the var named section to be created for each var as it's added. However as soon as I load the 'Settings' page for the theme, weather by clicking the tab link or or the main theme edit link (which loads the Settings page by default), the file gets re-writen to this text:

    Code

    this = that
    those = these
    thus = is


    And that's just a big ol monkey wrench and the vars no longer show up on the themes 'Variables' page.

    I think it's a bug, which I will file if it doesn't exist, but are we missing something?



    edited by: Topiatic, Feb 05, 2008 - 10:15 PM

    --
    Under Construction!
  • I agree. I think there are bugs there. I just can't figure out which of the unexpected behaviors are intentional, so I can't pinpoint where the bug is. I'm muddling through the code now, finding it a bit tough. You see, I just started seriously playing with 0.8 in the past week or so and I've found the old familiar pnVarCleanFromInput and others replaced with This::Util and That::Util, so I'm having to dig into those to see how everything flows.

    Anyway, if I just knew how it was expected to behave, I could track down the problem. But at this point I'm left to guess at the proper behavior based on my preferences (usually not exactly on the mark). So, I suppose your best bet is to file a bug report. I'd have done it, but I couldn't think of anything more intelligent to say than "I don't understand how theme variables are supposed to work" and that's really not a good title for a bug.
  • I disagree. I works for me, but may be I am missing the mark, here.

    We will start with his variables (prewritten).

    Code

    [variables]
    template = 2col
    layout = c

    [template]
    type = select
    values = 2col,3col,grid
    output = 2col,3col,grid

    [layout]

    type = select
    values = c,c_2cb,lc,lc_2cb,cr,cr_2cb,lcr,lcr_2cb,lcr_cb,lcr_2cb_cb,clr,clr_3b,crl,crl_3b,cr_eb
    output = c,c_2cb,lc,lc_2cb,cr,cr_2cb,lcr,lcr_2cb,lcr_cb,lcr_2cb_cb,clr,clr_3b,crl,crl_3b,cr_eb


    Now, I decide this needs a value of that. So I go to my admin|modifytheme|variables and add Name: this Value: that (and click the check (go)) Now the admin tells me I have:

    template|2col
    layout|2c
    this|that

    as expected.
    I go to my server grab the templatevariables.ini to verify.

    Code

    [variables]
    template = 2col
    layout = c
    this = that

    [template]

    type = select
    values = 2col,3col,grid
    output = 2col,3col,grid

    [layout]

    type = select
    values = c,c_2cb,lc,lc_2cb,cr,cr_2cb,lcr,lcr_2cb,lcr_cb,lcr_2cb_cb,clr,clr_3b,crl,crl_3b,cr_eb
    output = c,c_2cb,lc,lc_2cb,cr,cr_2cb,lcr,lcr_2cb,lcr_cb,lcr_2cb_cb,clr,clr_3b,crl,crl_3b,cr_eb


    again as expected...






    --
    David Pahl
    Zikula Support Team
  • Certainly not the result I get, but I'm going to try starting with a fresh templatevariables.ini file based on what you posted above. Mine doesn't look anything like that. I don't know if it ever did. I'm using a third-party theme and I just assumed everything was right. I'm guessing that maybe if you start with an incorrectly formatted (or blank) templatevariables.ini file, the system just sort of breaks down. I'll report back when I get some results.
  • I'd be intersted in seeing your variables file to see if I can work out how it got it way. If you package up the theme and send it to me (markwest at postnuke dot com) that would be great.

    Also, i've not seen it anywhere in the thread, make sure you're using at least RC2 or one of the recent daily builds.

    -Mark

    --
    Visit My homepage and Zikula themes.
  • Yeah Mark, I'm using RC2. I've actually fixed the templatevariables.ini file by hand for the theme in question and I don't want to break it because my partner is working with it trying to get the colors right, but I'll copy the theme over and break it, then bundle it up and send it to you some time tomorrow. I have the original third party theme that I used as a base to get started (learning from others' work ya know) on my laptop, but I don't remember what it is or where I got it at the moment or I'd tell you just to grab it and start adding theme variables through the admin interface. That's all I did. Anyway, when I get into the office tomorrow, I'll shoot you a message.
  • What types are available? I tried to setup a variable with type 'textarea' but it only used a text field. Can you use checkboxes? How about an HTML field?


    Another thing I found out is that if you want a text field to carry an URL or other text that includes a equal sign, you need to set the variable's field using quotes:


    Code

    topnavurl = "index.php?module=Pages"




    edited by: Wendell, Jul 05, 2008 - 08:59 AM

    --
    "Inside every large script (Zikula) is another script (Pagesetter) struggling to get out."

    IE6DWX Logo

This list is based on the users active over the last 60 minutes.