HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Why is there so much markup in php files?

I'm new to Vanilla and I'm working on a pretty drastic visual departure for a theme. In the process I find myself having to edit a few files that have php and logic in them. Mainly the helper.php files. This worries me regarding upgrades later. I'm curious why vanilla doesn't have more template files where the majority of the markup lives. I feel like this would make upgrades more feasible without the possibility of breaking as new features are added. IMO it would also allow for much easier themeing.



  • BleistivtBleistivt Moderator
    edited September 2015

    Because it is discouraged to edit core files. Even copying the views to your theme - try not to do it. There is almost always a way to do what you want by just editing the master view, editing the stylesheet or by using theme hooks.

    What are you trying to do exactly? Maybe we can help you.

  • R_JR_J Ex-Fanboy Munich Admin

    By now I think the usage of Smarty in Vanilla is a bad joke. It is used for the main template, but not for the themes. If you decide to use a template language you should use it consequently and the views directories should only contain Smarty tpl files. To my opinion, all view files should be converted to Smarty templates for the main Vanilla theme in order to stay consistent.

  • edited September 2015


    While the design has changed a touch since this prototype was last touched, you can get an idea of the forum skin I'm trying to build. This was built before I realized we were going to use Vanilla.

    This is a pretty heavy fully responsive modification and I don't know how easy this would be to accomplish using only CSS and the master view template.

    One of the biggest issues I have with Vanilla is that it relies so heavily on the "panel" sidebar for navigation and the panel changes a lot depending on which part of the site you're on. I want my categories permanently in the hamburger nav. And then I'll use a secondary nav solution for pages that require a special sidebar (ie - user profile).

    Anyway, if you have tips for how I can accomplish all of what I'm trying to do without modifying more than just the master view template, I'm all for it!


  • @R_J These are my thoughts exactly! I feel like Vanilla would be WAY more flexible for themers if they would move to such a structure.

  • @R_J schrieb:
    To my opinion, all view files should be converted to Smarty templates for the main Vanilla theme in order to stay consistent.

    Why even bother with outdated Smarty and all the needed custom plugins at this stage; isn't pure PHP an even better templating engine?

  • Smarty or not, I think logic and markup should be separated. Right now there's a ton of markup in the helper.php and other files. If you could change the markup without touching the logic and feature based code, then you have the potential to have themes very easily avoid upgrade issues.

    Say a new feature is added. If it affects the helper.php file my theme will be messing with this new feature. However if all of the markup were in an isolated file, I wouldn't need to overwrite the helper file and my theme would still function on the latest software. I'd just need to update the template file to allocate a place for the new feature.

  • R_JR_J Ex-Fanboy Munich Admin

    Well, I hate Smarty and I do not find it is a good fit to Vanilla. But using a heavy weight templating engine only for such a small part is overkill. Using Smarty everywhere might help designers, but it would at least be consequent. I prefer plain php but there are security benefits in using an additional templating engine

  • mtschirsmtschirs ✭✭✭
    edited September 2015

    @yourfavorite The helper.php files you can find in some views are kind of a crude way of reusing view components. They are on a controller level what functions.render.php is on an application or global (garden) level. Both just don't feel right.

    @R_J I agree.

  • @yourfavorite Just looked at your prototype which looks really nice.

    For implementing it in vanilla, I'd rip out the header and panel entirely.
    You could just add this in your template to have the categories module permanently:

    {module name="CategoriesModule"}

    ...but I believe that the panel is not a right fit for what you want to do.

    This can be used to detect in what section your are in (see the .Section-* class on the body):

    {if InSection("Profile")}

    If you need a lot of custom logic in your sidebar, I recommend building your own smarty function for this and including it in your theme.

    As for categories and threads, I don't see why the markup would have to be changed. It is similar to vanilla in its structure.

    I see you are also a fan of fully clickable rows, so I may suggest http://vanillaforums.org/addon/increaseclicktargets-plugin

  • edited September 2015


    Thanks for the info. This has opened up a lot for me and I think I can get a lot done by using hooks within my themehooks file and creating plugins for a few of the things I want to do (such as unique icons/images per category).

    What I haven't figured out yet is how to modify certain markup bits. As an example...

    If you look at the category heading for my prototype: http://caseybritt.com/_tmp/tr42/category.php

    The HTML looks like this:

    < div class="icon col-1">
        < img src="images/tmp/rando-icon.png">
    < /div>
    < div class="info col-5">
        < h1>Rando< /h1>
        < div class="post-count">12,346 posts< /div>
    < /div>

    I've figured out that I can insert the post count after the category title by using the hook "CategoriesController_AfterPageTitle_Handler". Similarly I can insert the icon div before the title using "CategoriesController_BeforeRenderAsset_Handler" and checking for "$Sender->EventArguments['NewDiscussionModule']".

    The problem comes when I need to add the div in the code above with the class of "info col-5". It wraps the h1 and the post count so that I can have them left align together next to the icon. If I don't have this, then the post count and the h1 will not align and the post count will sit below the icon. I can probably hack together some CSS to fix this, but for the sake of potential future issues like this, let's assume I absolutely need this "info" div to wrap the h1 and post count.

    In this particular instance I think I could probably put the opening of the "info col-5" div in the "CategoriesController_BeforeRenderAsset_Handler" hook and the closing tag after the post-count div in the "CategoriesController_AfterPageTitle_Handler" hook. I worry that it won't always be this simple going forward. Also I could see this getting out of hand and losing track of where opening and closing tags are because they're echo'd in two different hooks. Any tips or recommendations for this?

  • If you are trying to use boostrap or similar you build process need to merge into Vanilla selectors. It is a flawed methodology to modify views only to put selectors in there.

    Just pointing this out in advance so it doesn't bite you.

    I also suggest that modules might be a good option for some of your features, you can order modules within a container.

    grep is your friend.

  • BleistivtBleistivt Moderator
    edited September 2015

    Also I could see this getting out of hand and losing track of where opening and closing tags are because they're echo'd in two different hooks.

    You are right, I would avoid doing this.

    You could also try using a background-image for the icon. In fact I would make use of vanillas category image functionality for convenience. You would then always have the icon available val('Photo', $this->data('Category')) and it could be changed in the dashboard.

    The most painless way is probably building this part as a module like @x00 suggested:

    which would give you complete freedom. Then hide the original category title and description.

  • That makes a lot of sense. Thanks @Bleistivt!

    I've added a module and referenced it in my master tpl file, but to reference it in a plugin/themehook I assume that this is the process:

    Though instead of the plugin file I'd just do it in my themehooks file?

  • Yes, themehooks have the full power of plugins.

    The AssetTarget of your module would then be Content

  • If I do AssetTarget doesn't it just spit my module at the top of the Content section of my theme? Is there a way to control where it goes within the content section? Obviously at the top works for this instance but say I wanted it at the bottom or in the middle of the output.

  • I've written something about that on panels here:

    It works just like that with content assets.
    This is the configuration setting:

    $Configuration['Modules']['Vanilla']['Content'] = array('MessageModule', 'MeModule', 'UserBoxModule', 'NewDiscussionModule', 'ProfileOptionsModule', 'Notices', 'NewConversationModule', 'NewDiscussionModule', 'DiscussionFilterModule', 'CategoryModeratorsModule', 'Content', 'Ads');
  • Thanks @Bleistivt. You've been tons of help. I'm sure I'll be back to bother you before this process is over. ;)

  • vrijvlindervrijvlinder Papillon-Sauvage MVP

    You can also try using the CategoriesBg plugin to see how to do that with the categories.

  • edited September 2015

    Hey @Bleistivt. I followed your lead for the category header and just kind of inserted my own using my themehooks file. Then using CSS I hid the default stuff. And its working well!

    I am not sure how to handle this for the individual discussions in the list though. Here are the changes I need to make to the HTML structure of each discussion in the list.

    • Add author and timestamp below title and wrap both title, author and timestamp in a new div.
    • Wrap most recent reply author/timestamp in a new div.
    • Wrap reply count and most recent reply author/timestamp in a new div.

    Doing these three things will allow me to achieve the layout in my prototype across all breakpoints. What is the best approach for this? Surely hiding vanilla's default elements and injecting my own HTML that duplicates all data is not the best approach.

  • I wouldn't think so much in terms of markup but rather how you want it look.

    That said, you can overwrite the discussion row markup by copying this part:
    ...into your theme hooks file below the class body.

Sign In or Register to comment.