**Custom Theme Fields (Subtitle/Source) Not Detected by WP All Import/Export — How to Export/Import?**
Hello Newspaper Team,
I have been using the Newspaper theme for many years and have built multiple websites with it.
Recently, after a long break, I started a new project again using Newspaper and encountered an issue related to
bulk export/import of posts.
***Problem description***
When exporting and importing posts using popular WordPress plugins (such as WP All Export / WP All Import
and similar tools), the custom post fields provided by the Newspaper theme are not visible
in the export/import interface.
Specifically, fields such as:
- Subtitle
- Source (source URL)
- and other theme-specific post fields
do not appear as available custom fields for export or import. Because of this, it is impossible to correctly migrate
or bulk import content that relies on these fields.
I will attach screenshots to this post showing:
- the custom fields as they appear in the post editor
- and the fact that these fields are missing in export/import plugins
https://skrinshoter.ru/sZJcDa0Pwp2
https://skrinshoter.ru/sZJVE0W9t2u
***My questions***
- Are these fields stored in a non-standard way (for example, outside of regular post meta)?
- Is there an official or recommended way to make Newspaper custom fields visible to export/import plugins?
-
Can you recommend:
- a specific plugin,
- a configuration,
- or a developer-level solution
that allows proper bulk export/import of these fields?
-
If this is a theme-side limitation, would it be possible (or planned) to expose these fields as standard post meta
so that third-party plugins can detect them?
This functionality is critical for projects with large content volumes and site migrations.
Thank you in advance for your help and guidance. I appreciate your work on the Newspaper theme and look forward to your
recommendations.
Best regards,
Aleksey
Hi Aleksey,
If you use a migration duplicate plugin for the website, then everything will be the same or if you want to only import and export the articles, then just use the wordpress tool for import and export and this will import all data https://learn.wordpress.org/tutorial/tools-import-and-export/
Thank you!
Hi Calin,
Thank you for the clarification.
I’d like to add an important detail about my use case, because the main problem is not only importing articles into a new site.
In many real scenarios, I already have:
- an existing website,
- hundreds or thousands of published posts,
- content migrated from another theme or setup.
After switching to Newspaper, theme-specific fields such as Subtitle, Source, etc. are empty — and I need a way to
mass update or fill these fields for already published posts.
This is where standard WordPress Import/Export or full site migration tools do not fully solve the problem:
- full migration copies everything “as is”, but does not help when data needs to be changed or enriched,
- WordPress Tools → Export/Import does not allow structured mapping or bulk editing of specific fields,
- modern workflows rely heavily on bulk operations (CSV/XML-based import/export), not manual editing.
From a practical standpoint, it feels quite strange in 2025 that theme custom fields cannot be reliably detected and mass-edited via import/export tools.
Ten years ago, editing fields manually was acceptable. Today, many projects depend on scalable content operations, migrations, and automation.
That’s why I’d like to ask more directly:
- Does Newspaper officially support bulk editing / bulk updating of its custom post fields for existing posts?
- Are there plans to make these fields fully compatible with third-party import/export tools by exposing them as standard post meta?
- If this is not currently supported, is this something that could be addressed in future updates?
I really like the Newspaper theme and have used it for many projects, but between the limitations of the page editor and now this issue with custom fields,
it does raise concerns about long-term scalability compared to other modern themes.
I’m asking this not as a complaint, but to understand whether this limitation is:
- a known issue,
- a design decision,
- or something that may be improved soon.
Thanks again for your time and transparency.
Best regards,
Aleksey
Hi Aleksey,
I understand your point of view, but I believe the issue can be resolved in a simpler way. There is no need to import the custom fields from the old theme into the theme settings (Newspaper theme). Instead, it would be better to import them as standard custom fields (as those created with ACF plugin) and then display them using the theme’s custom field elements.
Additionally, you can create your own modules, which can display these custom fields directly inside the blocks.
Thank you.
Hi Calin,
Thank you for the detailed reply. I understand the workaround you are suggesting, however I’d like to clarify why this does not fully address the core issue.
Using ACF instead of Newspaper’s native post fields is technically possible, but in practice this means abandoning the theme’s built-in content system rather than solving the problem with it.
The main concerns with this approach are:
• The Newspaper theme already provides native fields such as Subtitle and Source, which are tightly integrated into post templates and modules.
• Suggesting to replace them with ACF fields means duplicating functionality that already exists in the theme.
• For long-term projects, this creates extra technical debt and dependency on custom solutions instead of using the theme as intended.
More importantly, this does not solve the original problem: mass editing and updating theme-specific fields for already published posts.
My expectation is not necessarily that Newspaper fields must use WP All Import specifically, but that:
• theme custom fields can be treated as standard post meta,
• they can be accessed programmatically,
• and they can be updated in bulk via modern content workflows.
So I’d like to ask more directly, from an architectural standpoint:
• Are Newspaper’s native post fields (Subtitle, Source, etc.) designed to be mass-editable for existing posts, or not?
• Are these fields intentionally isolated from standard post meta and third-party tools?
• Is this a conscious design decision, or a technical limitation of the current implementation?
If the official recommendation is to avoid using Newspaper’s native post fields for scalable projects and instead rely on ACF or custom modules, it would be very helpful to state this clearly in the documentation.
I’m trying to evaluate Newspaper for long-term, content-heavy projects, and this point is critical for that decision.
Thank you for your honesty and clarification.
Best regards,
Aleksey
Hi Aleksey,
I understand what you’re saying. Unfortunately, the theme doesn’t use standard fields for these parameters and instead has a more complex system for storing them. For example, the subtitle meta key field is td_post_theme_settings, and you’ll need to look for the meta_value td_subtitle – https://i.imgur.com/3gU7I0s.png
All of the theme’s fields are structured in this way, which can make creating the import correctly quite challenging.
Therefore, at the moment, I don’t know of any ready-made solution for this. It might be possible for a developer to create an import tool that focuses only on the fields that need to be imported/exported and checks whether those fields exist in the theme. Unfortunately, this is not covered by support, so you would need a developer to handle it.
Hi Calin,
Thank you for the honest and detailed explanation.
I have to say that this is quite disappointing for me. This architecture significantly complicates working with content at scale and makes common workflows like bulk editing, migration, and automation much harder than expected.
My main concern is that I want to focus on content creation and content management, not on building custom import tools or writing and maintaining custom code just to work with basic post fields such as subtitles or sources.
Given that there is:
no ready-made solution,
no official support for bulk import/export of theme fields,
and no recommended workflow for large content projects,
this limitation may force me to reconsider using the Newspaper theme and look at alternative themes that rely on standard WordPress data structures.
I appreciate your transparency, but for content-heavy projects, this is a critical limitation.
Thank you for your time and clarification.
Best regards,
Aleksey
Hi Aleksey,
I totally understand where you’re coming from, and your frustration makes complete sense, especially when you’re dealing with large amounts of content and need efficient, scalable workflows. The theme’s architecture can work well in some scenarios, but I agree that it becomes restrictive when bulk editing, migrations, or automation are essential.
I’m genuinely sorry that this limitation puts you in a position where you have to reconsider your options.
Thanks again for taking the time to explain your perspective so clearly.
