Hi Vlad,

I’ll check this in the development clone later, I had to revert to 10.3.9.1 to release the new website.

When I do I’ll report back for people to follow.

Thank you.

The issue was to do with the version of the child-theme css being enqueued.

To resolve this I added time() as an extra part of the version number when being enqueued until development was over.

A correction for people:

get_stylesheet_uri()

Should be:

get_stylesheet_directory_uri()

Hello Calin,

Sorry for the delayed response.

Well, writing over the parent style-buddypress.css file didn’t work, so I tracked down the enqueued name for it. style-buddypress.css is enqueued as ‘td-theme-buddypress’.

So it’s very easy to take it over, buy dequeuing it then renenquing it in child functions.php file.

function renenquing_buddypress_styles() {
wp_dequeue_style( 'td-theme-buddypress' );
wp_enqueue_style('td-theme-buddypress', get_stylesheet_uri() . '/style-buddypress.css');
}
add_action('wp_enqueue_scripts', 'renenquing_buddypress_styles');

Thank you for your assistance.

Hi Calin,

Thank you for that update. That page you’ve linked is more informative than the other Buddypress pages on style support I’d seen. I am quite curious as to your findings.

I’ve tried the following with respect to the td-composer plugin and the child-theme.

child-theme root = /

/menu-mobile.php
/parts/menu-mobile.php
/legacy/Newspaper/parts/menu-mobile.php
/td-composer/legacy/Newspaper/parts/menu-mobile.php

Unfortunately, none of these has worked for me. So it’s likely an unsupported file.

Btw I think it’s great that tagDiv offers this form of child-theme support, very forward-thinking considering how complex your theme is and its use of additional plugins.

/td-composer/legacy/Newspaper/parts/

This is the folder I am finding I need to modify files, like:

logged.php
menu-mobile.php
login.php

Thanks!

Richard

Hello Calin,

I needed to make adjustments to the css for BuddyPress related page elements. All of them. For example, changing the background colour of the buttons that are hoovered over. A simple example:

#buddypress a.button:hover span,
a.bp-title-button:hover span,
#buddypress ul.button-nav li a:hover span,
#buddypress a.button:focus span,
a.bp-title-button:focus span,
#buddypress ul.button-nav li a:focus span,
#buddypress a.button:active span,
a.bp-title-button:active span,
#buddypress ul.button-nav li a:active span {
background-color: #a11ff2;
}

I have way more edits and changes that are needed. I could target this directly from the child theme css file. But this isn’t the correct way to do this according to BuddyPress documentation.

BuddyPress requests that a separate companion CSS file be offered, style-buddypress.css is the file Newspaper is using. However, it’s not being enqueued via functions.php, so it must be somewhere else in the theme’s additional plugin that it’s being setup. Having an edited version in the child-theme doesn’t work.

If the mechanism behind enqueuing this style-buddypress.css file can be understood, it’s probably easier to de-enqueue and re-enqueue for the child theme file instead.

For me, this isn’t as much of an issue anymore as I need to be patching changes that aren’t compatible with the child-theme model you use. i.e. modifying the mobile menu header files. Your documentation on child-theme supported overrides only works for td-standard, not td-composer.

td-composer/legacy/Newspaper/parts/menu-mobile.php

So I’ll copy over the style-buddypres.css into the parent with my edited version as part of the patching. There’s no rush for a response now on my behalf.

Knowing the correct way of doing this would be helpful for others in the future and maybe added to the child-theme documentation.

Thank you and have a nice day.

I apologize, I’ve been dealing with a monster of a website that’s over 25GB in size and it’s taken its toll. I’ve gone through, more than 50 iterations of complex development already and manually doing the theme settings is tedious at best on a site this size so many times.

I let my frustrations out and that’s unprofessional.

It’s not my place to ask anything of tagdiv, you’ve provided a working export/import tool that works for 99% of your customers. Doing something so bespoke is outside of acceptable support. There are numerous reasons why a database import/export may not work as could generally be expected.

My reason for initially adding to this thread is to add a warning, that a simple database import/export won’t work for the actual settings. As the OP found out, but likely under different circumstances. Saving other developers in the future some lost time, thinking they can.

If a feature request can be offered, please can an export/import endpoint be considered for your API. This would save that 1% a tremendous amount of work and their sanity.

Thank you for producing an awesome theme, it’s truly exceptional!

Hello Calin, sorry you can address me as Richard, PFC is simply the acronym for the charity that owns the license.

Environment: Multipress WordPress with 12 sites, each site is a separate language version of the main site.

Here’s the issue explained in much greater detail:

I’ve manually injected pages and even manually translated block names ect… No issues, all restore as I want.

Same with widgets, including translations for them. No issues. All restore as I want.

It is ONLY the main theme settings that have an issue!

Injecting td_011 and/or td_011_settings does NOTHING! Like the OP found and first reported. Even injecting every newspaper-related field from wp_options back into the database does nothing for the colours, logo’s etc… It’s as if I never set these options. (except it’s clearly in the database, and snapshot dates show in theme panel, but not useable/clickable) the front page is just black and white.

SQL query “WHERE option_name LIKE ‘%td_%'” will give you all the table entries. See Appendix.

I am doing them all, including transients, caches, you name it ANYTHING tagdev related is recovered back into the database on the same domain, same version. I did them all as I wasn’t getting anywhere with just td_011 and td_011_settings. Recovering an exact 1:1 of all your database stored data should work.

So I make all the changes in my little dev-clone and I manually export all the table options I need (see appendix), re-importing these back into a new clone does nothing (see method), only when I use the theme panel importer tool does it work and logo’s colours ect… all show properly? (I had an older copy of the export hash)

It seems you know why, as you’ve stated it MUST be done through the exporter/importer when the OP said he couldn’t recover td_011_settings.

A 1:1 copy of all the database data related to Newspaper should theoretically just work, mitigating the need to use the importer tool.

Here are some questions:

1) what’s the difference between td_011 and td_011_settings, I think td_011 is a store of what’s active or not active in the themes state, plugins, demo’s et al. There seems to be some duplication of data within both fields.

2) Why will recovered td_011 and td_011_settings exactly as is via the database directly not work unless base64 encoded and put through your importer?

3) Since Tagdev is actively supporting further third-party development via an API, could an import/export endpoint please, be made in the future? We need a programmatical method.

4) I wanted to streamline the development and efficiency of not storing multiple copies of the same logos/assets in each subsite independently. So I made an images folder in the child theme and put the exact url to get this media in the theme settings. WARNING: It doesn’t work, clearly you must be using wp_posts ID somewhere. This needs to be made known as its more common practice to do as I was attempting.

5) td_011_settings is an autoload field, yet has all copies of the settings (backups/snaphosts), within this same field as just another index of an array in the serial blob. This is horribly inefficient for a user’s system. Why not just create a backups field like td_011_snapshots and pop an array in there without autoload set. (this has been mentioned before)

To others reading this: Autoload means it will load on every page load each time a database call is made to construct any page. If you have 10 backups, it’s now loading 10x the amount of data on every page load with 90% being completely unnecessary and redundant. It doesn’t matter if it’s 30KB, 300KB, or 1.3MB. This really should be addressed in my opinion.

I love your theme, it’s the best-selling theme of its kind for a reason. What am I possibly missing that stops a recovery of theme settings via the database directly actually working without the importer tool? I am I possibly missing a fieldname from the appendix?

Thank you for your time and response. It will be appreciated by more than just me that I am sure of.

Method:
1) Creating a local clone of live site, sed replacing old_domain with new_domain on sql dump prior to import. (new working clone)
2) Manually copying over theme files and child theme files, plugin files.
3) Activate and enable network-wide the theme plugins using wp-cli
4) Activate and enable network-wide the child theme using wp-cli
5) Ensure that needed media is imported into the system via wp-cli and that media names and uri’s match within database table entries (see appendix)
6) Inject all database table entries for tagdev stuff from the prior development cycle.
7) use wp-cli to restore widgets information

Pages on all subsites work beautifully, Widgets show correctly, just the colours, logo’s are missing! If I manually reimport using your importer on every subsite everything works like magic. It’s not missing media as they’re already imported and waiting.

Appendix:
_transient_td_update_theme_Newspaper
_transient_timeout_td_update_theme_Newspaper
td_011
td_011_remote_cache
td_011_settings
td_covid19_data
td_playlist_video_channel_id
td_playlist_video_video_ids
td_playlist_video_video_ids
td_playlist_videos_pool
widget_td_block_1_widget
.
.
.
widget_td_block_25_widget
widget_td_block_ad_box_widget
widget_td_block_author_widget
widget_td_block_authors_widget
widget_td_block_exchange_widget
widget_td_block_image_box_widget
widget_td_block_instagram_widget
widget_td_block_pinterest_widget

• This reply was modified 5 years by PFC.
• This reply was modified 5 years by PFC.

This is seriously disappointing. Why on earth can it not be restored on the database side?

Why MUST it use the backend form? An exact copy of the options tables for your theme, doesn’t work, it’s madness. All the form seems to do is decompile a base64 string of the settings that are in the database.

I’ve been trying to inject the settings from a staging system into the database ready for a live website upgrade. Same data, version etc…

Why can this not be done like this?

I’ve wasted more than a week on this exact problem as I need to import the settings into a multipress setup with a dozen subsites and this was a critical part of my bespoke automated upgrade script.

Copying widgets works, just not the settings. SMH

• This reply was modified 5 years by PFC.