Tag Archives: Files

WordPress XML Files: What They Are and How to Open Them

[ad_1] WordPress XML files see a lot of use for me as a content creator, and site owner. They let me perform many different tasks when running a site, developing layouts and designs, and much more. For you, WordPress XML files can help you to run an online store, or even set up crucial Search Engine Optimization (SEO). In this comprehensive guide, I’ll walk you through what WordPress XML files are, the importance of them for the platform, and much more. First, let’s look at what these types of files are. What a WordPress XML File Is In my years of working with WordPress, I’ve come to appreciate the versatility of eXtensible Markup Language (XML) files. As the name implies, it’s a markup language that lets you store and transport data in a format that’s both human-readable and machine-readable. My opinion is that XML is similar to HTML. However, while you use HTML to display data, XML describes and organizes it. This makes XML valuable for tasks in WordPress such as content migration, plugin configuration, and theme customization. Using XML files is a lot like using JSON in its application. For WordPress it plays a crucial role in various aspects of managing a site and shuttling data around. The Advantages of Using XML in WordPress There are a few positives in using XML over other formats relating to WordPress. First of all, XML provides a clear structure for complex data, which is useful for WordPress exports. What’s more, I can create custom XML structures for specific WordPress plugins or themes as I need to. For practical uses, XML is a great fit for WordPress: Compatibility. Various plugins and themes can read XML files, which makes data transfer between different WordPress installations or even different platforms smoother. Readability. Unlike some data formats, I can open an XML file and understand its contents, which is helpful if I need to troubleshoot a problem. Validity. You can validate XML documents against a schema, which ensures data integrity when you migrate WordPress content. These advantages means that WordPress XML files come in handy for a number of different tasks. Common Uses of XML Files in WordPress You’ll likely come across XML a lot when using WordPress. You can find the language in a number of areas, thanks to its readable format and simple customization: Content migration: WordPress uses the WordPress eXtended RSS (WXR) format to import and export content. WXR is a subset of XML, in that all WXR files are XML, but not the other way around. Plugin configuration. Some plugins use XML files to store complex configuration settings. Theme customization. You can sometimes use XML to define custom post types, taxonomies, or widget areas in classic themes. Content feeds. WordPress generates its syndicated content feeds in XML format for blog posts and user comments. Generating sitemaps. XML is the markup language a sitemap will use, and later, I’ll discuss how you can achieve this, and why a plugin could be the best option. API Interactions: Some external services interact with WordPress using XML-based APIs. I’ll look at a few of these aspects later, but before that, I want to show you the structure of an XML file and how to work with them. The Structure of WordPress XML Files I understand XML structure as three aspects. First up are elements. These are the building blocks of XML. In WordPress, you’ll often see elements such as , , or : My First Blog Post Welcome to my WordPress blog! From there, attributes provide additional information about those elements. For example, WordPress export files might use post_type or status: Finally, the date the element contains is its values. In practical terms, this will be whatever is in between elements: At the top of the XML file, there will likely be a declaration: This simply specifies the XML version and encoding the file uses. It’s similar to the declaration for that language. How to Open and Edit a WordPress XML File There are a few ways you can open an XML file within WordPress. Some are better than others, and I tend to opt for the simplest method unless I need to do heavy work on a file. For me, this is a text editor—TextEdit on the Mac: If you work on Windows, Notepad is just as good. Sometimes I will open the XML in a dedicated code editor, such as JetBrains’ PhpStorm: If I just want to quickly view the file structure (or the ‘tree’), I’ll drag-and-drop the file into a web browser window: There are other dedicated XML editors, such as XMLSpy or Oxygen XML Editor. However, I rarely (if ever) turn to these. For WordPress-specific tasks, they don’t hold much value for me. When editing XML files for WordPress, I try to remember and follow a few good practices: Always create a backup of the original XML file. Choose a tool that can read the WXR format, even if you may not work in that particular markup. Once you make your changes, I always validate the XML to catch any errors. I’ll take care with special characters. For instance, I’ll use entity references (such as & for &) when including special characters in content. Make sure to save the file with the correct encoding (usually UTF-8) to avoid issues with non-English content. Unless I work with web development projects that use JavaScript, PHP, CSS, and HTML files, I’ll simply open in a text editor. I may also use a lighter code editor to take a look, such as Sublime Text or my personal favorite, Onivim2. It all depends on the application and my specific need, and the options come in handy when deciding on the task at hand. Working With WordPress XML Files: 3 Use Cases I want to show you some typical ways you’ll use XML in WordPress. These are all tasks I carry out either very often or enough that it’s worth highlighting as part of my job: Let’s

Continue reading

Openverse Audio Catalog Passes 800,000 Files, Audio Support Now Out of Beta – WP Tavern

[ad_1] Openverse, formerly known as Creative Commons Search before it joined the WordPress project, has passed an important milestone with its support for audio files. The catalog has now indexed more than 800,000 audio files and its development team has taken audio support out of beta. Openverse visitors can now confidently search for and explore audio files for use in their videos, podcasts, or other creative projects, all available for free use under Creative Commons licenses. It is an incredible resource that is expanding and improving every day. Users can search on any device, but I found that Openverse audio searches and files are surprisingly easy to navigate on mobile. Search results can be filtered by permitted use, license, audio category, extension, duration, and source. Previewing works well and each file has attribution information readily available to copy. Clicking on “Get this audio” will take the visitor to the file on the external collection’s website where it can be downloaded. Deeper integration with WordPress core is on the roadmap for Openverse files. It would also be interesting to see WordPress’ core Audio block integrate access to Openverse, in addition to pulling files from URL or the media library, the same way the Image block allows users to browse Openverse. Gutenberg contributors are currently exploring how they can add basic Openverse integration to the inserter. Matias Ventura, lead architect of Gutenberg, has proposed adding a Media tab to the existing tabs for Blocks, Patterns, and Reusable blocks, which allow dragging and dropping content into the canvas. This would offer more convenient access to the media library while building pages. “The inserter panel should support the ability to drag media from the inserter into the canvas, including dragging into block placeholders to quickly update patterns and such with your own content,” Ventura said. “The Media tab would allow users to choose between categorized assets from the media library, and from Openverse.” Gutenberg engineer Nik Tsekouras created a PR with a prototype, basically a proof-of-concept, to explore how this might be implemented. Development is still in the exploration and early stages, but this looks like a promising new integration that would make it easy for WordPress users to tap into Openverse’s catalog of 600 million free creative works. [ad_2] Source link

Continue reading

Uploading via ZIP Files Preferred, SVN Access Forthcoming – WP Tavern

[ad_1] Earlier today, Dion Hulse announced the results of a six-week survey on the WordPress.org theme upload process. The goal was to figure out if uploading a ZIP file was a “pain point” and see what other methods theme authors prefer. Then, move forward based on the feedback. In total, 256 people responded to the survey. Of the weighted results, uploading themes via a ZIP remained the most popular option. Committing via Git or integrating with GitHub came in second and third, respectively. Using SVN or a CLI tool also had support. The next steps should include allowing theme updates to be submitted via SVN. Trac tickets will also be removed for updates, which the Themes Team no longer reviews. For theme authors who prefer Git, the plan is to encourage the use of a GitHub Action for automatic deployment over SVN. There are no tickets for implementing the changes yet, but they are forthcoming. Hulse said he is awaiting any feedback on the announcement post or in the Themes Team September 14 meeting. Nothing was said about the initial theme submission. This will likely remain the same. The upcoming SVN access will have some limits in comparison to plugins. Updates will be stored via a strict /theme-slug/version scheme with a standardized version format. Theme authors will not be allowed to change any commits once an update is submitted. Like the ZIP upload system, they will need to bump the version number to send a new update. The goal is for the theme repository to merely be a deployment destination and not a place for development. This should be a welcome change for those who have longed for alternative theme upload methods. As far back as I can remember, theme authors have asked for SVN access to the WordPress.org theme directory. It is a capability that plugin developers have long had. This was before the proliferation of Git and the rising popularity of GitHub. Every so often, themers would begin the discussion anew, but it would always end the same. Uploading a ZIP file was the only way to submit a new theme or an update to an existing one. Eventually, those discussions included talk of Git. However, it seemed most of the passion for integrating with any version control system (VCS) had waned. Most just lived with the status quo. This has not necessarily been a bad thing. Uploading a ZIP has kept the process simple. Theme authors could use their preferred VCS (or none) and ship the final product to WordPress.org. As I viewed the survey and thought it over, I changed positions. Throughout my history as a theme author, I was clearly in the camp calling for VCS integration. I wanted SVN (eventually, GIT) access to my projects in the directory. However, I had long ago customized my development build process to incorporate a ZIP creation step. The extra 30 seconds or so that it took to upload that file via the theme upload form did not seem to matter so much anymore. Like the plurality of others who responded to the survey, I now prefer uploading a ZIP file. Maybe it is what I am accustomed to, but it would not have been my answer a few years ago. I have come to appreciate the simplicity of the existing system. However, opening the theme upload process up to other methods should improve things for more people. In particular, I could imagine theme shops incorporating something similar to 10up’s GitHub Action for plugin deployment in their release process. Essentially, the Action automatically sends an update to WordPress.org’s SVN repository when tagging a release. Like this: Like Loading… [ad_2] Source link

Continue reading

Open Survey for WordPress Theme Authors on JSON Files and Block Themes – WP Tavern

[ad_1] WordPress 5.8 introduced an opt-in system for themes to configure block settings, styles, templates, and more. It is done through a new theme.json file that authors can put at the root of their theme folders. Anne McCarthy, the lead of the FSE Outreach Program, announced a survey earlier today to get feedback from developers on this feature. “Since this new mechanism is an early step towards a comprehensive style system for the future of WordPress, it’s important to hear from everyone who is currently using theme.json to learn more about how folks are using this tool and what might make sense to include in Core going forward,” she wrote in the announcement. The survey is open to all theme authors who have used theme.json, giving them a chance to put in some early feedback and help steer the ship going forward. Because I have worked extensively with this system over the past few months, I had a few things to say. Plus, I just like participating in WordPress-related surveys. I also decided it would be an opportunity to share some of my unfiltered thoughts from a development perspective on the current state of theme.json. What follows are my responses to the survey’s questions — well, the tidied-up version. Note: This is a developer-centric post that might not universally appeal to all of our readers. I have attempted to explain some things in user-friendly terminology, but some prerequisite knowledge of theme development may be necessary. Experience The first question of the survey is pretty cut-and-dry. It asks what your experience is with building block themes or using theme.json. It provides four choices (and an “other” option): I have built and launched block themes. I have experimented with building block themes. I have explored using theme.json with a classic theme. I have used a block theme, but I have not built one yet. I chose the first option because I have already built two block themes for family and friends. These were simple personal sites that I already maintain for free — honestly, I need to start charging. I am also working on a theme that I hope to release publicly. How It Started and How It’s Going The second question asks how one got started with block themes and theme.json. The choices are between forking an existing theme, using the Empty Theme, or starting from scratch. Again, this is one of those things where I have experimented with each direction, but I cannot remember the exact starting point. The bulk of my work has come from forking a theme that I last worked on in 2019. I plan to release this as a new theme for free at some point. I am mostly waiting on the following: Navigation block development to settle down The Post Author block to be split into smaller blocks A robust set of comment-related blocks Post Featured Image block to have a size option I think I could realistically release a use-at-your-own-risk beta version of my theme today if those items were addressed. Templates and Template Parts The survey asked which templates and template parts themers always include in their block-based themes. There was a freeform comment field — steps upon soapbox… I have a love/hate relationship with block templates at the moment. The static nature of HTML templates reminds me of simpler times when theme development was less complicated. However, this also presents a problem in a dynamic system. I cannot remember the last time I have built a traditional, PHP-based theme with more than one top-level template: index.php. The dynamic pieces have always been the guts of the thing, which are template parts. With PHP, it is easy to set some variable or use a function call to contextually load the templates parts necessary for whichever page a visitor is currently viewing on a site. The block template system does not work like that. It essentially forces developers into breaking the Don’t Repeat Yourself (DRY) principle. For example, if a designer wanted to display a different header template part for pages and posts, they would only need to create a header-page.php or header-post.php template in traditional themes. However, because the block template system is different, they must now create two top-level templates, single.html (post) and page.html, to accomplish the same thing. This is a “bad thing” because theme authors must duplicate all the other code in each of the top-level templates. There is no way to contextually load different template parts. To answer the question: I am using almost all of the possible top-level templates out of necessity. I also answered the second part of the question and listed my most commonly used template parts (broken down by hierarchy): Header Content– Loop– Sidebar Footer The content-*.html and loop-*.html template parts are those with the most variations. Defining Colors The next section of the survey asks how theme authors define their color palette slugs in theme.json. Believe it or not, naming colors may be the most controversial topic in the theming world in years. The only two things generally agreed upon are “background” and “foreground” colors. Morten Rand-Hendriksen opened a ticket in 2018 for standardizing a theme color naming scheme. It was not the first discussion and has not been the last. The problem it was meant to address was the slugs for colors in the system, which is how themes define their palettes. Once a user makes use of a preset color, the slug is hardcoded into their content. Switch to another theme with different slugs, and the old colors disappear and do not automatically change to the new theme’s colors. I use semantic names that follow something that closely resembles the Tailwind CSS framework’s shading system. Instead of red-medium (descriptive), I would use primary-500 (semantic), for example. A semantic approach would allow theme authors to define a set of colors that are updated each time a user switches themes. Of course, there are other schools of thought, and even everyone who prefers

Continue reading