htmlBurger

I think I understand now, you are trying to add content to the tabs and the above code is only for the tabs navigation, is that correct?

To add the tab content you can try the following:

Add a new rich text field to the complex for the actual tab content

Field::make( 'rich_text', 'rep_description', __( 'Description' ) )

Update the front-end to use the new field (this is just an example, you have to ajust it based on your project requirements)

<?php if ( $reps = carbon_get_the_post_meta( 'reps', 'complex' ) ): ?>
	<ul class="tabs-nav">
		<?php foreach ( $reps as $rep ): ?>
			<li class="tab col s6">
				<a href="#<?php echo sanitize_title_with_dashes( $rep['rep_last_name'] ); ?>">
					<?php echo $rep['rep_last_name'] . ' (' . $rep['rep_state_abb'] . '-' . $rep['rep_dist_num'] . ')'  ?>
				</a>
			</li>
		<?php endforeach ?>
	</ul>
	<ul class="tabs-content">
		<?php foreach ( $reps as $rep ): ?>
			<li class="tab-content" id="<?php echo sanitize_title_with_dashes( $rep['rep_last_name'] ); ?>">
				<?php echo wpautop( $rep['rep_description'] ); ?>
			</li>
		<?php endforeach ?>
	</ul>
<?php endif ?>

Hope this helps.

Thanks!

Hi there!

We’ve tried to create a fair comparison between Carbon Fields, ACF, and CMB2 here: https://carbonfields.net/about/

I know ACF has it’s own way of saving custom fields in DB, which seems to demand more queries then, for instance, CMB2.

Carbon Fields saves single row in the database per custom field value. So, we’re closer to CMB2 way of doing things than ACF.

How does CF relates to the forthcoming WordPress Fields API?

We’ll probably see how we can integrate Carbon Fields with the WordPress Fields API once it’s merged in the core. At this point we’re standing by until there is a release candidate that we can play with.

Hi Caspie,

Thanks for pointing that out. It appears there was an error in our documentation. We’ve fixed the error, adding another underscore for the field name prefix: https://github.com/htmlburger/carbon-fields-docs/commit/171b9b5bb89cce504c0956e2f9856542c32c8f27

Also, we’ve emphasized the fact that the field name is prefixed with an underscore in the relationship filters documentation.

In addition, the automatic prefixing with an underscore is already pointed out in the Fields -> Usage article in our documentation: https://carbonfields.net/docs/fields-usage/ and it includes a link to explanation why we prefix the fields with an underscore.

Thank you!

This is a PHP limitation, actually. You’re probably hitting the max_input_vars limit of PHP, because of too many input fields being submitted in one request.

To clarify, such issues can occur if you have hundreds of variations in a product in WooCommerce, for example.

Fortunately, you can increase this limit in your php.ini: http://php.net/manual/en/info.configuration.php#ini.max-input-vars

Please, let us know if you have further issues.

Yes, it is the master branch.
You can use GitHub to clone and pull it, or if you’re not familiar with Git, you can download it az a ZIP archive.

Howdy, @digitalthinkgers,

The Carbon Fields in the frontend is not a natively supported feature.

It can be done, but it requires some custom coding. It has been discussed here as well: https://ww.wp.xz.cn/support/topic/carbon-based-front-end-forms?replies=4

Regarding default value of a date, this is easy – just call ->set_default_value( date( 'Y-m-d H:i:s' ) ) on the field after creating it with make() or factory().

Thank you.