• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

button apply between elements or order button apply

...Or you can just do it all with javascript/jQuery and css - and avoid having to make changes to any of the Fabrik core code, templates, or layouts.

Examples of code included in the form_xx.js file...

If the form is new, hide Submit button and fix the border radius of the remaining apply button...
JavaScript:
if (jQuery("tablename___id").val()==""){
    jQuery("button[name='Submit']").hide();
    jQuery("button[name='apply']").css({"border-top-left-radius":"4px","border-bottom-left-radius":"4px"});
}

Hide apply button and fix the border radius of the Submit button...
JavaScript:
jQuery("button[name='apply']").hide();
jQuery("button[name='Submit']").css({"border-top-right-radius":"4px","border-bottom-right-radius":"4px"});

Switch the order of the Submit/apply buttons (it looks like Fabrik will take care of the border radius so long as both Apply and Submit is shown)...
JavaScript:
jQuery("button[name='Submit']").insertAfter(jQuery("button[name='apply']"));

Insert a button after the control-group div of an element
JavaScript:
jQuery("div.fb_el_tablename___elementname").after('<button type="button" class="btn button" onclick="parent.location=\'https://www.yourdomain.com/page-alias\'" name="TestButton">ButtonLabel</button>');

Change the HTML of the Goback button to redirect to a certain page...
JavaScript:
jQuery("button[name='Goback']").closest("div").html('<button type="button" class="btn button" onclick="parent.location=\'https://www.yourdomain.com/page-alias\'" name="Goback"><i data-isicon="true" class="back"></i>&nbsp;Cancel/Go back</button>');

Add a class to a button for css styling...
JavaScript:
jQuery("button[name='apply']").addClass("isnew");

CSS:
button.isnew {
    background: darkgreen;
}

If you use the php form plugin for post processing, you can add a certain value to a button to help identify code that needs to be run in a certain situation, or where to redirect.
JavaScript:
jQuery("button[name='Submit']").prop("value","toList");
You will know which 'submit' button was clicked because it will be a key name included in the form $data. For example, if apply was clicked there will be a $data['apply']-> and if Submit was clicked there will be a $data['Submit']->
(or if the last example was used you will see $data['Submit']->toList )

The general rule is the apply button submits the form and returns to the same form/page (unless changes to certain watch elements apply/'kick in' access restrictions which prevent that, in which case the view is changed to details rather than edit) - while the Submit button saves the form and returns to the list view (unless redirected).
 
Last edited:
Yes - but when you do that, then you become responsible for maintaining it. So if I were to write code that changed the way (say) view.html.php and default_actions.php worked then the new functionality wouldn't get carried across to the override file. So to use a real example of my PR for class support for buttons - you might find that classes made it to the back end settings page, but then didn't display and you would be left scratching your head wondering why because you had forgotten that you had implemented the default_actions.php override.

So IMO my comment stands - try as much as possible to stick with the way Fabrik does things and only change them with overrides if absolutely necessary.

Then you might as well just say "don't use any layout or template or language overrides anywhere in Joomla because you might forget you did it". Which would drastically restrict the ability to customize. That's the whole point of overrides, so you CAN change the way the CMS or 3rd party extensions renders things, and you don't have to restrict yourself to "the way X does things".

I pretty strongly disagree with advice that says "don't use overrides for overriding things", alhough I do agree that there is an maintenance overhead, in that if what you overrode changes, you need to keep your override up to date. But I wouldn't have suggested this if it was in anything a) complex / difficult to maintain, or b) prone to frequent, backward compat breaking changes. I think we've changed that template file a handful of times since it was written, and only one (the dynamic grid naming) might have had an effect on future compat changes.

https://github.com/Fabrik/fabrik/co...views/form/tmpl/bootstrap/default_actions.php

-- hugh
 
On a related note, "one of these days" I'm going to add some debug code to insert the path of the template / layout file being used into an HTML comment, so it's obvious from the page source where any given markup is coming from, which would go a long way to making maintaining overrides easier, as at least you'd have an easy way of seeing which file needs attention, by appending &fabrikdebug=1 and checking the page source.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top