If you are using the CMS, then there should be an "Attributes" field under the "Advanced" tab when editing a menu item that you can add data-toggle="test" to. This will get added to the anchor link and not the containing li.
Regarding the proper us…
if you can't add it to the nav.php file, you can use the "append" attribute of fuel_nav() which can take an array of menu items in the same format as those found in the nav.php file.
The blog module uses the date function which doesn't support localization. You may need to use strtotime and convert it into a timestamp format that would allow you to further manipulate it (perhaps with http://php.net/manual/en/class.intldateformat…
Thanks for providing the code. That appears to be a bug. I've posted a fix in the develop branch which you can pull. The develop branch will contain the next release bug patches.
It should be. You would add it to the $nav array as specified above though and not as an option when callling the fuel_nav() function. What sort of problems were you seeing?
So these are variables set under the Pages module for a page or the Site Variables module? If the latter, have you tried:
<?=fuel_var('myvar', 'default', 'sitevariables')?>
Is the "fuel_mode" set to "auto" in your fuel/application/config/MY_fuel.php file? That message will appear if the variable being displayed isn't being pulled from the CMS (or the variable value doesn't exist)
How are you calling the inline editing in your code? Is it:
<?=fuel_var('myvar', 'default', 'sitevariables')?>
Note the 3rd parameter specifying to use sitevariables instead of pagevariables
Hmm... that is strange especially if you are able to get it through the $_POST (or $this->input->post). The $values array is essentially the $_POST values filtered down to just those applicable for the table to save. In your case, you had a pa…
Try adding it to the 'assets' one as well. That is sort of the catch all used for selecting file assets to upload in the Assets module. The 'docs' file types will be checked on upload.
So just to be clear, you have a field in your table of "package_id" and in your model, you have something like:
public $foreign_keys = array('package_id' => 'packages_model');
Then in your on_before_validate method you have something like:
functi…
That sounds like you may want to add something in your model's form_fields method to return the code for that albums photos. You could create a custom field type that does this:
http://docs.getfuelcms.com/general/forms#association_parameters
I'm having a tough time recreating the issue locally. What browser are you using? On line 198 in the fuel/modules/fuel/assets/js/fuel/custom_fields.js file there is a part of the wysiwyg function that swaps out the img_path function. There is also a…
That would require some custom coding. The fuel/modules/fuel/libraries/Fuel_custom_fields::asset() method handles the rendering of that field along with the fuel.fields.asset_field function in the fuel/modules/fuel/assets/js/fuel/custom_fields.js fi…
The buggy part is that you should be able to upload HTML files but you can't (only .txt and .php). I pushed a change to the develop branch yesterday which you can pull from that should allow you to upload html files.
Is there a SQL query that gets outputted if you place this after that line (assuming calendar_posts_model is the name of your model):
$this->calendar_posts_model->debug_query();
The upload function is intended for uploading CI view files. Your layout needs to have a field of "body" for it to work. That looks to be a bug, which I'll post a fix for shortly in the develop branch (the next patch release of FUEL).
In the fuel_assets_model.php file, on line 138, there is a strpos function call in 2 spots. Does your issue get fixed if it is changed to "stripos" instead?
Is this with the latest version? Also, what does the source code look like (so you by chance have "style" tags in your HTML)? And is this consistent across browsers?