ACF Button Style CSS

—

### ✅ 1. **Create Your CSS File**
Create a file named something like `acf-blocks.css` or `custom-button.css` in your theme (usually in `assets/css/` or `resources/css/` depending on your setup):

/* custom-button.css */
.acf-custom-button {
  background-color: #3498db;
  color: white;
  padding: 10px 20px;
  border: none;
  text-align: center;
  cursor: pointer;
  transition: background-color 0.3s ease;
}

.acf-custom-button:hover {
  background-color: #2980b9;
}

—

### ✅ 2. **Enqueue the CSS File in `functions.php`**
Add this to your theme’s `functions.php` to load the stylesheet:

function enqueue_acf_custom_styles() {
    wp_enqueue_style('acf-custom-button', get_template_directory_uri() . '/assets/css/custom-button.css', [], '1.0');
}
add_action('wp_enqueue_scripts', 'enqueue_acf_custom_styles');

> 🔁 Adjust the path if your file is stored in a different directory.

—

### ✅ 3. **Apply the Class in ACF Block or Field Output**
When rendering the button from your ACF block or custom field, add the class to the button element:

<button class="acf-custom-button">
  <?php the_field('button_text'); ?>
</button>

Or if you're using an ACF block template file:

<a href="<?php the_field('button_url'); ?>" class="acf-custom-button">
  <?php the_field('button_label'); ?>
</a>

—

### 🧠 Bonus: Make Button Colors Dynamic via ACF (Optional)
If you want to allow the user to choose colors in the admin:

1. Add **color picker fields** in ACF (e.g., `button_bg_color`, `button_hover_color`).
2. Output them inline or with dynamic class generation using a “ block or CSS variables.

Let me know if you want that dynamic color logic too.

—

### ✅ Option 1: Use CSS Variables + External CSS (Best of Both Worlds)

#### 1. **Your External CSS File (`custom-button.css`)**

/* custom-button.css */
.acf-custom-button {
  background-color: var(--btn-bg-color, #3498db);
  color: var(--btn-text-color, #fff);
  padding: 10px 20px;
  border: none;
  cursor: pointer;
  transition: background-color 0.3s ease;
}

.acf-custom-button:hover {
  background-color: var(--btn-hover-bg-color, #2980b9);
}

#### 2. **Render the Button with ACF Color Fields (in PHP template)**

Assuming your color fields are:
– `button_bg_color`
– `button_text_color`
– `button_hover_color`

<?php
$bg_color     = get_field('button_bg_color');
$text_color   = get_field('button_text_color');
$hover_color  = get_field('button_hover_color');
?>

<div style="--btn-bg-color: <?= esc_attr($bg_color); ?>; --btn-text-color: <?= esc_attr($text_color); ?>; --btn-hover-bg-color: <?= esc_attr($hover_color); ?>;">
  <a href="<?php the_field('button_link'); ?>" class="acf-custom-button">
    <?php the_field('button_label'); ?>
  </a>
</div>

✅ This approach lets your `custom-button.css` file stay separate, while the actual color values are injected dynamically using inline CSS variables.

—

### ✅ Option 2: Inject Inline Style (if you don’t want CSS variables)

<?php
$bg_color     = get_field('button_bg_color');
$text_color   = get_field('button_text_color');
$hover_color  = get_field('button_hover_color');
?>

<style>
  .acf-custom-button.dynamic {
    background-color: <?= esc_attr($bg_color); ?>;
    color: <?= esc_attr($text_color); ?>;
  }

  .acf-custom-button.dynamic:hover {
    background-color: <?= esc_attr($hover_color); ?>;
  }
</style>

<a href="<?php the_field('button_link'); ?>" class="acf-custom-button dynamic">
  <?php the_field('button_label'); ?>
</a>

—

### 💡 Which One Should You Use?

– ✅ **Option 1 (CSS variables)** — clean, scalable, better for reusable components.
– ✅ **Option 2 (inline “)** — simpler for one-off use, but harder to manage with many buttons.

Let me know which approach you prefer, or if you need help applying this inside an ACF block or flexible content field!

composer update vendor/package-name

### 🔧 Example:

If you want to update `guzzlehttp/guzzle`, you'd run:

composer update guzzlehttp/guzzle

—

### ✅ Notes:

1. This will:
– Respect version constraints in your `composer.json`.
– Only update the specified package (and its dependencies if needed).

2. If you want to **ignore version constraints** and update to the latest version allowed (even a major one), use:

composer update vendor/package-name --with-all-dependencies

—

### 🧠 Bonus Tip:
To see what version is currently installed and what versions are available:

composer show vendor/package-name

Let me know if you want to pin a specific version or troubleshoot dependency conflicts.

—

### 🧱 Add (Install) a New Package:

composer require vendor/package-name

### 🔧 Example:

composer require guzzlehttp/guzzle

This will:

– Download the latest compatible version.
– Add it to your `composer.json` file under `require`.
– Install it in the `vendor/` directory.

—

### ✅ Optional Flags:

– **Specific version**:

composer require guzzlehttp/guzzle:^7.0

– **Dev-only package**:

composer require --dev phpunit/phpunit

Let me know the package you want to add and I’ll help with the exact command!

—

### ✅ Step 1: Check Current Version Constraint

Open your `composer.json` and find:

"roots/wordpress-core-installer": "1.100.0"

Or similar. To allow updating to `2.0.0`, you must loosen the version constraint, for example:

"roots/wordpress-core-installer": "^2.0"

> `^2.0` allows updates from `2.0.0` up to but not including `3.0.0`.

—

### ✅ Step 2: Run Composer Update

After updating the constraint, run:

composer update roots/wordpress-core-installer

—

### ✅ Step 3: Confirm the Update

Use:

composer show roots/wordpress-core-installer

To verify the installed version is `2.0.0`.

—

### ⚠️ Important Notes:
– **v2.0.0** might include **breaking changes**. Check the [changelog](https://github.com/roots/wordpress-core-installer/releases) or the [GitHub repo](https://github.com/roots/wordpress-core-installer) before updating.
– If you're using Bedrock or a custom installer, ensure it’s compatible with v2.0.0.

Want help checking for breaking changes or adjusting your setup for the update?

—

### ✅ Command to update directly via CLI:

composer require roots/wordpress-core-installer:^2.0 --no-update
composer update roots/wordpress-core-installer

Or in a single command:

composer require roots/wordpress-core-installer:^2.0

—

### 🔍 What this does:
– `composer require` updates your `composer.json` with `^2.0`
– It then installs the latest version allowed (`2.0.0` in this case)
– If you skip `^2.0`, Composer will stick to the constraint already in your `composer.json` (like `1.x`)

—

### ✅ Confirm Update

After that, verify with:

composer show roots/wordpress-core-installer

You should see `versions : * 2.0.0`.

Let me know if you want to test compatibility before committing the update.

Problem 1
– Root composer.json requires roots/wordpress-core-installer ^2.0, found roots/wordpress-core-installer[2.0.0] but these were not loaded, likely because it conflicts with another require.
Problem 2
– roots/wordpress is locked to version 6.7.2 and an update of this package was not requested.
– roots/wordpress 6.7.2 requires roots/wordpress-core-installer ^1.0.0 -> found roots/wordpress-core-installer[1.0.0, 1.1.0, 1.100.0] but it conflicts with your root composer.json require (^2.0).

Use the option –with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Your project is using:

– `roots/wordpress` (locked at `6.7.2`)
– which **requires** `roots/wordpress-core-installer ^1.0.0`
– But you're trying to install `^2.0`, which **conflicts** with that.

—

### ✅ Solution: Update both packages together

Run this command to update `roots/wordpress-core-installer` **along with** the packages that depend on it (in this case, `roots/wordpress`):

composer require roots/wordpress-core-installer:^2.0 -W

Or more safely:

composer update roots/wordpress-core-installer roots/wordpress --with-all-dependencies

> `-W` / `–with-all-dependencies` tells Composer: "Update whatever else needs to change to satisfy the new version."

—

### ✅ Optional: Check for Compatibility

Before you commit the update, you may want to check if:

– `roots/wordpress` has a version that supports `roots/wordpress-core-installer:^2.0`
– You are not using any plugin/theme/tool that relies on the old installer behavior

Let me know if you'd like help with that check or reviewing breaking changes.