Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • in reply to: Animated changing color background #304110

    Hey Marie,

    I’m not support, but I was browsing around and what you’re asking is fairly simple, but you will need some rudimentary CSS3 knowledge. The source for the All Blogger Tricks example gives you everything you need.

    First thing you need to do is add a custom ID to your color section, for example, calling it “colorchange”. Don’t set a custom background color in order to keep any specificity conflicts out of play.

    Next, you need some custom CSS:

    #colorchange {
        -webkit-animation: colorBackground 20s infinite;
        animation: colorBackground 20s infinite;
    @-webkit-keyframes colorBackground {
        0% { background-color: #fbcf61; }
        20% { background-color: #6bd57e; }
        40% { background-color: #ff6f6f; }
        60% { background-color: #57cff4; }
        80% { background-color: #0ed4c8; }
        100% { background-color: #fbcf61; }
    @keyframes colorBackground {
        0% { background-color: #fbcf61; }
        20% { background-color: #6bd57e; }
        40% { background-color: #ff6f6f; }
        60% { background-color: #57cff4; }
        80% { background-color: #0ed4c8; }
        100% { background-color: #fbcf61; }

    And that’s it. I think that should be all you need in terms of browser prefixes, too. I’m not sure what your level of knowledge is, but anything with “-webkit” in front of it should be the same as the unprefixed version. You can add keyframes by adding more in-between percentages (e.g. 0%, 10%, 20%, 30%, and so on), but this gives you five colors (first and last keyframes should be the same). You can change them by changing the background-color hex values. Keep in mind this won’t work in IE8 or IE9.

    Gradients are currently not animatable with CSS, so you would need a JavaScript solution like the one you linked. In that one, it looks like you have to set the desired colors as RGB values in an array and target a specific div in jQuery, so you need to know how to do that and enqueue the JavaScript for it in WordPress. I don’t have time for that tutorial, but a freelancer could probably set you up in like 10-20 minutes to be honest.

    in reply to: Disable Enfold menu #302912

    Hi again,

    I’m sorry that got rid of the Enfold custom widget area creator. I’m not sure how that is possible, and it works fine in my own version of Enfold. I guess you will have to just wait for the official release.

    To add to what Josue has said, what is shown in his screenshot will appear if you put add_theme_support( 'avia_conditionals_for_mega_menu' ); in functions.php (or better yet, your child theme’s functions.php). I was deliberately vague about it in case the support staff thought the Nav Menu Roles plugin was the better way to go, but that’s how you do it. I believe it will only work if you have not also commented out add_theme_support('avia_mega_menu');, and the line in class-megamenu.php also becomes unnecessary.

    in reply to: Disable Enfold menu #302878

    Hi guys,

    Nav Menu Roles does not yet work with the public version Enfold. I know because I am pretty sure I’m the guy who helped get support for it (and a few other menu plugins) in the upcoming version. I am guessing staff dev versions are a little ahead of the public version here.

    It is easy enough to add this code to line 510 or so of class-megamenu.php until the release:

    do_action( 'wp_nav_menu_item_custom_fields', $item_id, $item, $depth, $args );

    But, actually, I’m surprised everyone forgot about add_theme_support( 'avia_conditionals_for_mega_menu' ); ;) That should solve it without a plugin.

    • This reply was modified 9 years, 6 months ago by mayorninja.

    Hey killyman, since I’m free for a second I guess I will answer this too. Why not? :)

    The easiest method to get rid of the post date and author without affecting other pages would be to put this in your quick CSS:

    #top.single-event .fullsize .template-blog .post-meta-infos {
        display: none;

    And the sharing icons are actually being obstructed by the post delimiter in front of them. To solve this you just need to give it a visibility of hidden like on normal blog pages:

    #top.single-event .fullsize .template-blog .post_delimiter {
        visibility: hidden;

    That should do it. @Ismael, I think if I had to answer as many support questions a day as you, I would sometimes miss something too. :)

    I think the problem is killyman is not using The Events Calendar from Modern Tribe, he’s using Events Manager, as he said in his first post and in the title. I’m not sure about what kind of conditionals are possible with Events Manager, but it looks to me like it uses a custom post type called “event” and it also looks like killyman just embedded a shortcode in a page called “Screenings,” without caring about an event archive or any of that, and wants that as the parent. So, I would propose that the filter should look like this:

    add_filter('avf_title_args', 'fix_events_page_title', 10, 2);
    function fix_events_page_title($args, $id)
    	if (is_singular('event'))
    		$args['title'] = 'Screenings';
    		$args['link'] = get_permalink(get_page_by_title('Screenings'));
    	return $args;

    Hey ttem and anyone else interested,

    I was actually looking for something similar, didn’t find much, and so I came up with my own solution. I didn’t want to add a search icon next to the mobile menu trigger just because I don’t think a little pop-up search form is great UI on mobile, so this works inside the mobile menu. Maybe in the future one of those “cover the header” or “slide down from the top” search forms could work, but to be honest, that’s too much work at the moment, and I’d prefer it if Kriesi just added more search form options or something. This method is quick and easy.

    Since the advanced mobile menu is created on the fly with jQuery, and is nested in a z-index that makes forcing only a single element up from the regular header annoyingly difficult at best, I went with a simple jQuery solution, that can be put wherever (maybe just some plugin that places custom JS in the footer):

    jQuery(window).load(function() {
        jQuery('#mobile-advanced').append('<li><form id="searchform" method="get"><div><input id="searchsubmit" class="button avia-font-entypo-fontello" type="submit" value=""></input><input id="s" type="text" placeholder="Search" value="" name="s" autocomplete="off"></input></div></form></li>');

    This places a form below your menu items in the mobile menu (you could also use prepend). Some caveats with this are all the IDs should be changed to something else (and then you’ll need to do some restyling), autocomplete is off because it acts a little weird for reasons I don’t care to figure out, and you’ll still have to do some styling like adding padding, but the code as is will work right away and look kind of okay.

    in reply to: Enfold Feature Requests #234358

    I’m not even sure if this is a good idea because of potential downsides, but I may have a suggestion to improve the mega menu editing interface. It’s probably one of the least important things possible to worry about, but hey, might as well post it.

    I actually think what you have now is really great and very functional, but it’s a little odd from a UX standpoint. You can tell it’s engineered to get around WordPress’ limitations (which is not your fault of course). Check a box to make a mega menu, and suddenly pages or custom links turn into columns. Drag them in a level deeper, and they’re pages and custom links again. Check another box, and now the description is a thing you can use to put custom content in. Not bad, just kind of weird.

    Some months ago, a little-known plugin was released called Big Voodoo Mega Menu & Related Links Menu. While it falls flat in its front-end implementation, the back-end is pretty good. Here’s a look at it. Columns and what Enfold calls text blocks are their own separate elements, with their own properties, and I think it works well.

    Downsides vs. the current Enfold way are:

    • It’s not as easy to link to a page from a column heading (since you can’t just make a page also a column with this method)
    • Pages and text blocks can be on the same level as columns, which would be layout chaos
    • There’s nothing stopping you from making a column or text block a top level item, which would also be layout chaos.

    But maybe there’s a clever way to solve those issues, like still doing the “page becomes a column” thing if a user is absolutely insisting, and a JavaScript check to keep columns inside the second level and text blocks inside the third level (although what do you do about adding them to the menu initially?). And, on the other hand, maybe it’s not a big deal, and users will use the tools as intended.

    Anyway, I think it’s more intuitive, but a lot easier to break, so I’m not sure if it’s a useful suggestion. I’ll let you decide.

    in reply to: Small bug report — logo scaling in FF25/OSX #188264

    Oh, right, thank you, I know… I am just reporting the issues so that they can possibly be corrected in the next version.

    To summarize it, image-rendering on images may need to be removed or changed to auto as you suggested, icon fonts could benefit from using the brand new -moz-osx-font-smoothing: grayscale on OS X, and adding font-weight: normal to the search icon in the menu would look better in Firefox.

    in reply to: Enfold Feature Requests #178802

    I’m really liking how well-thought-out the masonry elements were (I’m not surprised Kriesi nailed it yet again though), but they have prompted me to suggest going back and improving some of the older elements at some point soon.

    For example, the masonry options include things for activating an overlay or not, displaying the title on hover, gap space between items, etc., and the portfolio element has none of that. Similarly, the content and logo sliders have transition options, options for the type of controls, and a place for a heading, and the post slider does not. Both of those neglected older elements are probably more major and are probably used more than the new ones, but they have hardly been improved since the start. I’d bet anything that you guys are already aware of this, but I personally think it would be best to make everything more coherent sooner rather than later.

    It also seems like Kriesi’s aesthetic choices have become noticeably more refined in the past six months or so (the classy look of the masonry layout is on a level above the normal portfolio grid, and they don’t really look like they belong to the same theme), so it might be a good idea to go back and review the design of some older elements with fresh eyes.

    Regarding the actual masonry elements, I wonder if it’s really necessary to force them to be full width. I modified things a little, shrunk it down to half width, and it seemed to work okay, except for the fact that the columns got too narrow. But, they could be responsive at the element level with this cool library. It’s not like masonry layouts work without JavaScript anyway.

    Also, I think using tags to make a masonry element wider or taller is awkward. Meta box options would be better, because they help make the user aware of the purpose, rather than have them discover the option and how to do it in a modal window and then go back and use a standard WordPress feature for something other than its intended purpose. More importantly, though, because it affects the front end and what a viewer sees. The Enfold demo has “landscape” and “portrait” tags listed in blog posts when they would probably have nothing to do with the content if it was a real site, and it could affect things like tag clouds too.

    All in all, I think it would have been better to make masonry layouts an option for the blog and portfolio elements instead of having to choose options from one or the other, but I can think of a few reasons why this would be tricky, so it’s fine. It does look like one unified blog/portfolio/masonry flexible element could work pretty well on the next theme.

    Sorry I wrote so much! I’m really verbose and I couldn’t figure out how to cut it down.

    in reply to: Entypo Font Update #135579

    Just so you guys know, I think the big issue with Fontello is the encoding of the font files. I think a while back, Fontello switched its default from ASCII or Unicode to Private Use Area encoding — basically, the section of the Unicode range that intentionally has no characters assigned by default, so anyone can use it for their own thing without conflicts. My theory is Kriesi encoded his Entypo version as Unicode, and that’s the snag.

    The “cartoony icons” are OS X’s (maybe others too) default emojis, because the PUA encoding of the font in this case means there is no “font override” going on for those Unicode characters, like there is when you encode as Unicode.

    Unless I made a very stupid mistake and mixed up the files, I removed the Enfold default icon fonts, tried replacing them with PUA and ASCII encoding, just to experiment (didn’t work), then made a new Unicode-encoded file, and the icons were restored. So, just be sure to click that wrench icon next to the download button on Fontello, scroll down to “Set Encoding,” and select Unicode, and that should fix it.

    in reply to: Gravity Forms in columns leads to extra line breaks #123498

    Quick update, I did try a different [raw] method and it simply doesn’t affect it at all instead of spitting out the shortcode without executing it. In any case, it doesn’t help.

Viewing 11 posts - 1 through 11 (of 11 total)