WordPress Importers: Stating the Problem  ## Metadata - Author: [[Gary]] - Full Title: WordPress Importers: Stating the Problem - Category: #articles - Document Note: --- tags: #WordPressImporters #CMS #OpenSource Author: AI Assistant Source: AI Generated Reference: N/A --- # Title: WordPress Importers: A Necessity for the Future ## Table of Contents: - History of WordPress Importers - New Services and CMS needs - The Importance of Owning Your Content - Challenges and Opportunities for Future Development ## Index Creation: - WordPress Importers - Open Source Commitment - Modern CMS Services - Site Ownership - Content Migration ## 📝 Summary: The WordPress Importers are a crucial aspect of WordPress' success story and commitment to Open Source. However, with the rise of new CMS services, challenges have emerged concerning content migration, ownership, and the need for continuous development of importers to adapt to changing requirements. ## 📖 Main Content: The WordPress Importers played a significant role in WordPress' early success by allowing users to migrate from other platforms easily. Over time, importers were moved to plugins, leading to limited development as export formats remained stable. New CMS services lack importers for WordPress, posing challenges to content migration. WordPress's focus on content ownership and freedom highlights the importance of robust importers. ### 🗒️ Notes: - WordPress Importers were vital in attracting users from other platforms. - Lack of new importer development hinders compatibility with modern CMS services. - Content ownership and freedom are central to WordPress's philosophy. - Challenges in current importers necessitate an update to support future needs. ## 📖 References: No external references cited. ## 🗣️ Paraphrase: 1. The WordPress Importers have been instrumental in the platform's success, facilitating seamless migration from other services. 2. Modern CMS services require importers that can adapt to changing content formats and structures. ## 🧪 Hypotheses: 1. New importer development will enhance compatibility with diverse CMS services. 2. Improving importers can support WordPress's values of content ownership and freedom. ### 📊 Methodology: - Conduct user surveys to identify common challenges in content migration. - Collaborate with CMS services to develop standardized export formats for seamless imports. ### ❓ Questions: - How can WordPress importers adapt to evolving content formats? - What strategies can enhance content migration for users switching platforms? ### 🔮 Future Research: Exploring AI-driven solutions for content migration. Investigating the impact of advanced importers on user adoption rates. ### 💡 Implications: Enhanced importers can strengthen user trust and loyalty. Improved content migration tools can differentiate WordPress from competitors. ### ✅ Logical validity: The arguments presented emphasize the need for updated importers to support the changing landscape of CMS services, rooted in WordPress's principles of freedom and ownership. ## 🎯 Conclusion: In conclusion, the future of WordPress Importers lies in their adaptability to modern CMS services, content requirements, and the evolving needs of users. By focusing on the development of robust importers, WordPress can maintain its position as a leading platform for content management. - Document Tags: [[data liberation]] [[wordpress]] - Summary: The document discusses the importance of WordPress Importers, emphasizing their role in the early success of WordPress and the need to update them to keep up with new CMS services. It highlights the challenges faced by WordPress in importing from services like Wix and GoDaddy Website Builder that restrict content export. The document calls for maintaining the ethos of freedom in content ownership and suggests expanding the importers' capabilities to address the evolving demands of modern websites. - URL: https://pento.net/2021/01/18/wordpress-importers-stating-the-problem/ It’s time to focus on the WordPress Importers. I’m not talking about tidying them up, or improve performance, or fixing some bugs, though these are certainly things that should happen. Instead, we need to consider their purpose, how they fit as a driver of WordPress’ commitment to Open Source, and how they can be a key element in helping to keep the Internet Open and Free. #### The History The WordPress Importers are arguably *the* key driver to WordPress’ early success. Before the importer plugins existed (before WordPress even supported plugins!) there were a handful of `import-*.php` scripts in the [`wp-admin` directory](https://core.trac.wordpress.org/browser/trunk/wp-admin?rev=688) that could be used to import blogs from other blogging platforms. When other platforms fell out of favour, WordPress already had an importer ready for people to move their site over. One of the most notable instances was in 2004, [when Moveable Type changed their license and prices](https://github.com/WordPress/book/blob/trunk/Content/Part%202/9-freedom-zero.md), suddenly requiring personal blog authors to pay for something that had previously been free. WordPress was fortunate enough to be in the right place at the right time: many of WordPress’ earliest users came from Moveable Type. As time went on, WordPress became well known in its own right. Growth relied less on people wanting to switch from another provider, and more on people choosing to start their site with WordPress. For [practical reasons](https://core.trac.wordpress.org/ticket/13307), the importers were moved out of WordPress Core, and into their own plugins. Since then, they’ve largely been in maintenance mode: bugs are fixed when they come up, but since export formats rarely change, they’ve just continued to work for all these years. An unfortunate side effect of this, however, is that new importers are rarely written. While a new breed of services have sprung up over the years, the WordPress importers haven’t kept up. #### The New Services There are many new CMS services that have cropped up in recent years, and we don’t have importers for any of them. WordPress.com has a few extra ones written, but they’ve been built on the WordPress.com infrastructure out of necessity. You see, we’ve always assumed that other CMSes will provide some sort of export file that we can use to import into WordPress. That isn’t always the case, however. Some services (notable, [Wix](https://support.wix.com/en/article/exporting-or-embedding-your-wix-site-elsewhere) and [GoDaddy Website Builder](https://godaddy.com/community/Websites-Marketing-Website/Exporting-Website-Builder-Site-to-Word-Press/td-p/124526)) deliberately don’t allow you to export your own content. Other services provide incomplete or fragmented exports, needlessly forcing stress upon site owners who want to use their own content outside of that service. To work around this, WordPress.com has implemented importers that effectively scrape the site: while this has worked to some degree, it does require regular maintenance, and the importer has to do a lot of guessing about how the content should be transformed. This is clearly not a solution that would be maintainable as a plugin. **Some services work against their customers, and actively prevent site owners from controlling their own content.** This strikes at the heart of the [WordPress Bill of Rights](https://wordpress.org/about/#bill-of-rights). WordPress is built with fundamental freedoms in mind: all of those freedoms point to owning your content, and being able to make use of it in any form you like. When a CMS actively works against providing such freedom to their community, I would argue that we have an obligation to help that community out. #### A Variety of Content It’s worth discussing how, when starting a modern CMS service, the bar for success is very high. You can’t get away with just providing a basic CMS: you need to provide all the options. Blogs, eCommerce, mailing lists, forums, themes, polls, statistics, contact forms, integrations, embeds, the list goes on. The closest comparison to modern CMS services is… the *entire* WordPress ecosystem: built on WordPress core, but with the myriad of plugins and themes available, along with the variety of services offered by a huge array of companies. So, when we talk about the importers, we need to consider how they’ll be used. **To import from a modern CMS service into WordPress, your importer needs to map from service features to WordPress plugins.** #### Getting Our Own House In Order Some of these problems don’t just apply to new services, however. Out of the box, WordPress exports to WXR (WordPress eXtended RSS) files: an XML file that contains the *content* of the site. Back when WXR was first created, this was all you really needed, but much like the rest of the WordPress importers, it hasn’t kept up with the times. A modern WordPress site isn’t just the sum of its content: a WordPress site has plugins and themes. It has various options configured, it has huge quantities of media, it has masses of text content, far more than the first WordPress sites ever had. **WXR doesn’t contain a full export of a WordPress site.** In my view, WXR is a solid format for handling exports. An XML-based system is quite capable of containing all forms of content, so it’s reasonable that we could expand the WXR format to contain the entire site. #### Built for the Future If there’s one thing we can learn from the history of the WordPress importers, it’s that maintenance will potentially be sporadic. Importers are unlikely to receive the same attention that the broader WordPress Core project does, owners may come and go. An importer will get attention if it breaks, of course, but it otherwise may go months or years without changing. **We can’t depend on regular importer maintenance in the future.** It’s quite possible to build code that will be running in 10+ years: we see examples all across the WordPress ecosystem. Doing it in a reliable fashion needs to be a deliberate choice, however. #### What’s Next? Having worked our way down from the larger philosophical reasons for the importers, to some of the more technically-oriented implementation problems; I’d like to work our way back out again, focussing on each problem individually. In the following posts, I’ll start laying out how I think we can bring our importers up to speed, prepare them for the future, and make them available for everyone., WordPress Importers: Stating the Problem, Gary, 01hq0vgmwvgxtet000wanxx10j.