We did also encounter a serious issue during the theme update process. We followed the steps as listed: Change to other theme, delete old them, upload new theme, change back to new theme, and everything worked aside from widgets.

This process appears to have destroyed the widgets for the default sidebar and footer. Newspaper default, Footer 1, Footer 2, and Footer 3

Please find a way to allow updating the theme without losing all widget settings, as we have a lot of specific configurations in said widgets, and this will cost us a few more hours to clean up.

Hi Simon,

I was hoping for phone support because having a 24 hour response time was growing concerning given that this issue has already resulted in what will be a one week delay in our product launch. At the scale we operate, one week of delay/down time for even a single product is a significant financial loss.

I’ve updated our theme and followed all steps and documentation provided, and we now have single_template_2.php working as it was before migrating to the previous “new” theme version.

Thanks again for your help on this. I’m glad we were able to get it resolved.

I just want it noted that I’m still very disappointed that this issue happened at all, and it has seriously shaken our confidence in tagDiv. Allowing a theme update to launch with a loss of such basic functionality was a massive oversight, as was not properly warning customers that upgrading or installing the new theme would mean losing or breaking existing features and functionality.

I’m also upset that the solution now relies on obfuscated legacy resources, and that this functionality is not incorporated cleanly into the product. The ability for a site owner to modify post templates is the most basic level of functionality expected of any theme. I understand that tagDiv is trying to simplify things for less technical users, but please keep in mind that your product is being used by companies who have come to depend on it and develop entire product lines around it. Such failings not only damage their relationship with tagDiv but have real consequences.

Please pass this along to tagDiv leadership.

Thanks again for the support.

What would the update process be for updating to this new theme when it comes out?

What would the process be to setup a child template, especially if the original templates don’t exist to clone as children?

Can I be notified the moment this is available, and is there a specific version number I’m looking for?

Again, at this point any amount of waiting is a real concern with significant costs associated, so we need to keep looking into alternative solutions. And I just want to reiterate (as you’ve mentioned it a second time) this is an order of magnitude beyond inconvenience. This blunder has cost us dearly, and continues to do so every hour we are delayed.

Is there someone I can talk to on the phone about this?

Thanks again.

Hi Simon,

Thanks for getting back to me.

I’m extremely concerned and upset that this theme was allowed to release updates that included such a crippling and significant step backward in functionality. There are companies that have built entire lines of business around this product, and such big (negative) changes can have tragic results. We depend heavily on this, the most basic of theme functionality. To discover that it was overlooked is quite shocking. I’ve never encountered a theme that took away the ability to modify posts templates as part of an “update.”

I don’t want to go into specifics, but a large scale project that has been in development for months that was scheduled to launch this week was just completely derailed by this oversight. This is far more than an inconvenience.

We’ve already built multiple products around your theme, and so far we have loved it. But this significant change really bit us.

So the big question is what are our next steps?

We are not able to wait for future versions of the theme to address this oversight, as we need to release on time or risk significant losses.

We are not able to roll back to an older version of the theme, as that would set us back days and undo a lot of hard work, which we don’t have time for.

I don’t want to hack a custom solution that will prevent us from updating to future versions of the theme, since we need to keep it up to date for security reasons. So whatever we come up with ideally needs to be future-proof.

Here are our basic needs:

We need to be able to identify posts of a certain category, and then modify the post to do the following (based on Custom Fields values inside the post)

Enable/disable the following post elements:
Title, Date Display, Featured Image, Social Links, Related Posts. These can not just be toggled via CSS as we need to optimize load times.

We also need to inject unique custom html (which will contain meta data, CSS, javascript, tracking codes, pixels, etc) into each post for a specific category. This HTML is also sourced via Custom Fields values.

Without those abilities we can’t launch. This was something we could easily tackle in our other Newspaper theme installs.

I’m looking into using the “add_filter” method to process the posts to strip out HTML elements based on the Custom Fields values, but have yet to find a way to make this work. I’m also looking to do the same for injecting the HTML.

Further complicating things is the fact that we did not budget (from a time, resource, or financial perspective) adding additional development to this project, since we are basically re-instancing an existing product build.

I’m hoping you can help advise us here.

I do appreciate your feedback, and hope we can find a solution to this issue.

Thanks again!

Thank you so much, that plugin was just what I needed!