htmlBurger

Glad that MightyBlocks is working well for you!

We’re still early in the development, hopefully soon you’ll have a reason to increase that review rating from 4 to 5 stars ??

Thanks,
Emil, Viktor & Georgi

Hi @vitaminnnka,

The data in the screenshot looks OK as well.

Can you try adding wp_enqueue_script( 'jquery' ) in the crb_enqueue_scripts() function?

If this doesn’t solve the issue, can you share the code with us with a read-only access to the repository or by sending it to us on [email protected] so we can try to reproduce the issue locally?

Instead of add_action( 'carbon_map_api_key', 'crb_get_gmaps_api_key' ); you should be using add_filter( 'carbon_map_api_key', 'crb_get_gmaps_api_key' );.

In addition, change $google_maps_api_key = ''; to $google_maps_api_key = crb_get_gmaps_api_key();

The rest seems OK.

Can you write <?php var_dump( $post ); var_dump( $map_data ); exit; ?> in the template and paste the result here? This way I can check if the correct values are being returned from carbon_get_post_meta() ??

Hi @vitaminnnka,

Can you send me the code which you are using to register the Map Field in the administration area?

Hi @vitaminnnka,

The $map_data variable contains the latitude and longitude that you’ve set in the administration area. In order to display a Google Map with these coordinates, you will have to use JavaScript to manually initialize the map.

Here is an example code:

<div class="map" id="map" style="height: 480px; width: 100%" data-lat="<?php echo $map_data['lat']; ?>" data-lng="<?php echo $map_data['lng']; ?>" data-zoom="<?php echo $map_data['zoom']; ?>"></div>

In functions.php load the Google Maps API:

add_action( 'wp_enqueue_script', 'crb_enqueue_scripts' );
function crb_enqueue_scripts() {
	$google_maps_api_key = ''; // get from https://developers.google.com/maps/documentation/javascript/get-api-key

	wp_enqueue_script( 'google-maps-api', '//maps.googleapis.com/maps/api/js?key=' . $google_maps_api_key );
	wp_enqueue_script( 'theme-scripts', get_stylesheet_directory_uri() . '/js/functions.js' );
}

And lastly in js/functions.js:

;(function ($, document, window, undefined) {

	$(document).ready(function () {
		var $map = $('#map');
		var lat = $map.data('lat');
		var lng = $map.data('lng');
		var zoom = $map.data('zoom');

		var center = { lat: lat, lng: lng };
		var mapOptions = { zoom: zoom, center: center };

		var map = new google.maps.Map( $map[0], mapOptions );

		new google.maps.Marker({
			map: map,
			position: center,
		})
	});
})(jQuery, document, window);

Hope this helps!

Let me know if you need more details ??

• This reply was modified 6 years ago by htmlBurger.

@satyajett we’re working on Gutenberg support, you can see the announcement here: https://carbonfields.net/2018/04/27/plans-for-carbon-fields-and-gutenberg-integration/

Hello @makszhukov97,

Sorry for the late reply!

You can use the ->set_width() method to set the occupied width of the field in its container.

For example, the following code will set both fields to take 50% of the width of the container they are placed in:

Field::make( 'text', 'crb_button_label', 'Button Label' )
  ->set_width( 50 ),
Field::make( 'text', 'crb_button_link', 'Button Link' )
  ->set_width( 50 ),

Please refer to the Width section of the Documentation for more information – https://carbonfields.net/docs/fields-usage/?crb_version=2-1-0

• This reply was modified 6 years, 8 months ago by htmlBurger.
• This reply was modified 6 years, 8 months ago by htmlBurger.

Hello @bagerathan

At this point we’re not quite sure whether(and how) to distribute Carbon Fields v2 via the WordPress plugin repository.

The best way to use Carbon Fields v2 is to install it via composer:
composer require htmlburger/carbon-fields

Carbon Fields is not really a plugin — it’s a library that could be used by plugin and theme authors. Carbon Fields, on itself doesn’t do anything – you need to write PHP code in order to utilize it. So the best way to update it is via composer update rather than from the WordPress admin.

This post describes those issues pretty well:

Please do not submit frameworks

For time being we’re releasing bugfix releases in the WordPress plugin repo(on the 1.X branch). We try hard not to introduce breaking changes there.

In future we’ll probably add a banner here in the WP repo that the latest version lives in github. Or we’ll just delete the plugin and maintain just the composer package.

Thanks!

• This reply was modified 7 years, 4 months ago by htmlBurger.

Hi Nikhil,

I glanced at Magic Fields’s source code and it seems to me that the plugin is using custom SQL table to store meta values(rather than the WordPress’ standard wp_postmeta table). This is unfortunate for you because you can’t easily switch to different plugin – you have several options:

* Add CarbonFields without removing MagicFields, define your custom fields in the new plugin, and manually copy-paste meta values in the administration; then, remove magic fields
* Install and setup CarbonFields, and create a script to migrate the data for you from MagicFields to standard post meta

Whichever option you choose, you should also go through your front-end theme code and switch the rendering code from magic fields to get_post_meta calls.

If I were you, I’d probably just add CarbonFields(without removing MagicFields) to the project and use that for new custom fields that are needed — I wouldn’t bother changing the old custom fields if they work fine. Both plugins should work just fine together.

If you need to add repeaters to existing custom fields that are defined in MagicFields, you could change just those fields instead of all fields in the project. This isn’t ideal, but it might be the best option if you’re constrained by time.

Closing this in favor of your GitHub issue here:
https://github.com/htmlburger/carbon-fields/issues/219

Hi @arkimedia

We’re aimed at public release for May 15th.

We’re currently testing the new version internally and working actively on:

* Backward compatibility testing and fixes (some things like extended fields will break, but we try to make upgrading from v1.5 to v2 less painful)
* Documentation – for new features as well as migration guides for old projects

We welcome any interested developers to try the new version by
composer require htmlburger/carbon-fields:dev-milestone/2_0/react-ui

Any feedback will be appreciated.

Thanks!

You can post a feature request over at GitHub (https://github.com/htmlburger/carbon-fields/issues) and we will discuss internally if we will be adding this soon.

In the meantime, you can try and adapt an ACF+Yoast plugin to work with CF (it looks like it’s a matter of switching some calls from get_fields() to carbon_get_post_meta() etc.). If you go that route, you may even post a PR on GitHub or post it as a separate plugin for CF.

Thanks for the kind words @matt-k-1, glad you like the plugin!

We definitely plan to add a gallery field and also many others, but right now we are doing a major overhaul of both back and front-end code, which pushes new features back.

If you are not willing to wait, here are some useful links (no tutorials, sorry) that might help you with the implementation of your own gallery field:

A boilerplate for making new fields: https://github.com/htmlburger/carbon-field-template
A gallery field made by the community: https://github.com/htmlburger/carbon-fields/pull/97

> Is there a way to create meta boxes on the side of theme_options pages?

Currently, set_context() is only supported for the post_meta container (as WordPress’ post edit screen is the only screen which defines display contexts for meta boxes).

> I’m not sure what the show_on_post_type($type) attribute is supposed to be.

show_on_post_type($type) limits the visibility of a post_meta container to one or more post types. For example, show_on_post_type('post') will only add the container to posts but not to pages or other custom post types that may be defined.

PS:

Looking at your code you are creating a post_meta container, not a theme_options one. You can read more on the different types of containers here: https://carbonfields.net/docs/containers-usage/

@jonwaldstein
Adding tabs to complex entries in the way you need is currently not supported. You can add tabs directly to containers or display each complex entry as a tab but cannot have tabs inside each complex entry.

To improve readability you can use the separator field but it will still be showing all fields inside the complex entry.