How to Customize the tagDiv Newspaper Theme When the Accent Color Won’t Change

You change the Newspaper theme’s accent color in the Theme Panel, save, and the header, menu and footer are still the old red. Then you try to adjust the phone layout outside the Composer and find every setting stored as base64-encoded JSON. Both have a reliable fix, step by step.

Three kinds of change, three places they live

Newspaper (tested here on version 12.7.9) splits its look across three stores, and each one has its own way in:

The first is quick. The other two are where the time goes.

Part 1: recolor the theme

Step 1. Set the accent in the Theme Panel. In wp-admin go to Newspaper → Theme Panel → Theme Colors and change the theme accent color, then Save Settings. That setting is stored with the theme’s own options and isn’t available through the REST API, so this one step stays manual.

Step 2. Expect the header and footer to stay the old color. They will. Newspaper’s header, menu and footer are Cloud Library templates, and their CSS was generated when each template was last saved, with the accent written in as a literal color. Changing the global accent doesn’t regenerate that CSS. On one test site, a month after switching the accent, the served homepage HTML still contained the old red #ec3535 189 times.

Re-saving each template in the Composer regenerates its CSS, but only colors stored as references to the accent pick up the change. Literal colors stay as they are, so a CSS override of the chrome is the more dependable route.

Changing the accent in the Theme Panel recolors content. The header and footer keep the color they were compiled with.

Step 3. Prefix every override with #td-outer-wrap. tagDiv’s generated rules look like .tdi_45 .x { color: #ec3535 !important; }. A plain .x { color: … !important; } loses to them, because when both sides use !important the more specific selector wins. Newspaper wraps the whole page in an element with the id td-outer-wrap, and an id outranks any number of classes. Starting each selector with #td-outer-wrap is the one trick that makes overrides stick on this theme.

Step 4. Never target the .tdi_ numbers. Those classes are instance ids that tagDiv regenerates whenever a template is recompiled; the test homepage carried 154 different ones. Target the theme’s stable class names instead (.td-post-category, .tds-button1, .td-social-sharing-button).

Step 5. Recolor button text with two properties. tagDiv sets button labels with -webkit-text-fill-color, which overrides color. Set only color and a filled button can end up with a violet label on a violet background, and the label simply disappears (a SUBSCRIBE button is the usual victim). Set both, and fill for SVG icons.

Here is a complete rule in that style. Category labels appear as plain links on articles but as filled chips on the homepage cards; this one makes them a chip with white text everywhere:

#td-outer-wrap .td-post-category,
#td-outer-wrap .td-post-category:hover {
    background-color: #7854f7 !important;
    color: #fff !important;
    -webkit-text-fill-color: #fff !important;
}
Code language: CSS (css)

Scope the overrides to the chrome. A blanket rule on body, a or every svg also repaints article figures and the deliberately black main menu.

Step 6. Test the override in the browser before you deploy it. In a logged-in tab, inject the candidate CSS as a <style> element through the developer console, then count how many elements still compute to the old color (red is rgb(236, 53, 53)) and repeat until none are left. Take a screenshot as well: a computed-color check can miss hidden duplicate header nodes and text drawn with -webkit-text-fill-color. Remove the test style afterwards, then deploy the CSS in a snippet.

Part 2: change the mobile layout by script

Step 1. Save the page’s raw content first. The Composer stores a page as shortcodes in its content. Fetch the raw version through the REST API with an editor credential (GET /wp-json/wp/v2/pages/<id>?context=edit, field content.raw) and keep it as a file. That file is your undo: posting it back restores the page exactly. (Expect it to be long: one test homepage ran to 65,012 characters.)

Step 2. Find the block and its responsive attributes. Each block is a shortcode, such as td_flex_block_2 or vc_row, written in square brackets with its settings as attributes. Settings that can differ by screen size are stored as base64-encoded JSON, with one key per device. Decoded, three from a test homepage read:

f_title_font_size  {"all":"40","portrait":"20","landscape":"30","phone":"22"}
image_floated      {"all":"hidden","phone":"float_left"}
show_excerpt       {"phone":"none"}Code language: JavaScript (javascript)

Spacing, borders and visibility live in tdc_css, which nests a set of CSS properties under each device (all, landscape, portrait, phone, plus breakpoint widths). The test homepage had 40 of them. (Why a theme would base64-encode its settings at all is a story of its own: it keeps the shortcode parser safe.)

Step 3. Change only the device you mean. Decode the attribute, change the phone value, encode it back in the same compact form, and leave every other key alone. Editing the encoded string directly, or running a search-and-replace over it, fails without an error.

Step 4. Make the script prove it is editing the right block. Pick the block by position, assert its type before touching it, and check afterwards that every container still opens and closes. A helper that does all three, reduced to its core:

import base64
import json
import re

BLOCK = re.compile(r"\[(td_flex_block_\w+|td_block_\w+|tdm_block_\w+|vc_row|vc_column|vc_row_inner|vc_column_inner)\b[^\]]*\]")


def decode(value):
    return json.loads(base64.b64decode(value + "=" * (-len(value) % 4)))


def encode(data):
    return base64.b64encode(json.dumps(data, separators=(",", ":")).encode()).decode()


def set_device(content, block_index, attr, device, value, expect_tag):
    """Set one device (e.g. "phone") of one responsive attribute on the Nth block, leaving every other device alone."""
    blocks = list(BLOCK.finditer(content))
    m = blocks[block_index]
    tag = m.group(0)
    assert m.group(1) == expect_tag, f"block {block_index} is {m.group(1)}, not {expect_tag}"  # wrong block: stop
    found = re.search(rf'\b{attr}="([^"]*)"', tag)
    data = decode(found.group(1)) if found and found.group(1) else {}
    if attr == "tdc_css":
        data.setdefault(device, {}).update(value)  # tdc_css nests a dict of CSS properties per device
    else:
        data[device] = value
    new_attr = f'{attr}="{encode(data)}"'
    new_tag = tag.replace(found.group(0), new_attr, 1) if found else tag[:-1] + f" {new_attr}]"
    return content[:m.start()] + new_tag + content[m.end():]


def balanced(content):
    """Every container that opens also closes, so the edit did not break the page structure."""
    for t in ("vc_row", "vc_row_inner", "vc_column", "vc_column_inner"):
        opened = len(re.findall(rf"\[{t}[\s\]]", content))
        if opened != content.count(f"[/{t}]"):
            return False
    return True
Code language: Python (python)

A call looks like set_device(raw, 2, "f_title_font_size", "phone", "24", expect_tag="td_flex_block_2"), or, for spacing, set_device(raw, 0, "tdc_css", "phone", {"padding-left": "16", "padding-right": "16"}, expect_tag="vc_row"). Run against a saved copy of a test homepage, the first call changed only the phone value (22 to 24), kept the other three devices, left the content length and everything outside that block unchanged, and kept every container balanced. Pointed at the wrong block, it stopped with “block 0 is vc_row, not td_flex_block_2” instead of writing.

A script that asserts which block it is editing can be run twice. One that doesn’t, you run once and then check by hand.

Step 5. Write back, then look at a phone. Send the whole edited content back as the page’s content and open the page at phone width, plus once on a desktop to confirm nothing else moved. Stage bigger changes as numbered steps, each saved to its own file, so any one of them can be compared or undone.

Step 6. Keep the undo file next to the change. If something looks wrong, posting the file from Step 1 puts the page back exactly as it was. Keep one per change, with a note of what each step altered.

Script or Composer?

The Composer can make all of these changes by hand, and for a single tweak it’s the quicker route. A script earns its place when the change has to be repeatable or reviewed: the same mobile fix on several blocks, a change someone else should check before it goes live, or one you may need to undo next week. The REST API’s limits with page builders are the other half of that decision.

The short version

• Three stores, three tools: the accent color in the Theme Panel, the chrome colors through CSS, the layout and mobile settings through the page’s Composer shortcodes.
• The header and footer keep their old color because Cloud Library templates compile it in; one test homepage still served the old red 189 times a month later.
• Prefix overrides with #td-outer-wrap, target stable classes rather than .tdi_ ids, and set both color and -webkit-text-fill-color on buttons.
• Mobile settings are base64 JSON with a key per device. Decode, change phone, re-encode, and assert the block before writing.
• Save the raw page first. Posting it back is a full undo.

Frequently Asked Questions

Why does my CSS override not work on the tagDiv Newspaper theme?

tagDiv’s own rules use !important and high specificity, so a plain class selector with !important loses. Start your selectors with #td-outer-wrap, the id of Newspaper’s page wrapper, which outranks class-only rules, and don’t target the .tdi_ numbered classes, which change whenever a template is recompiled.

Why is my button text invisible after recoloring the theme?

tagDiv sets button labels with -webkit-text-fill-color, which takes priority over color. If you recolor the button background but only set color on the label, the label can keep the accent color and vanish into the background. Set both properties, and fill for icon SVGs.

How do I decode a tdc_css value?

It is base64-encoded JSON. Decode the attribute’s value from base64, parse the result as JSON, and you get an object with a key per device. Re-encode in the same compact form (no spaces) after editing, and write back the whole page content.

Will a theme update undo my CSS override?

Not if the override lives in a snippet rather than in the theme’s own files, because an update replaces the theme’s files, not yours. What an update can break is a class name your selectors target, so after a major update repeat the browser check: count the elements that still compute to the old color, and take a screenshot.