Request for PCForge Updates: Compatibility Filters and Better Structure

Hello Tagdiv Team,

I hope you’re doing well. I’m reaching out to share some detailed feedback on the PCForge template in your Newspaper Theme. I think you’ve created something truly unique with PCForge, and I really appreciate your initiative in developing a WordPress-compatible PC builder tool—a feature no other theme provider has dared to approach. It has immense potential, and I’m very interested in using it for a project I’m working on.

The overall design is visually striking and the builder concept is incredibly useful, but I’ve encountered some structural and functionality issues that I believe could be improved. These adjustments would make PCForge even more valuable and practical, particularly for projects involving comprehensive component databases.

Structural Setup with Taxonomies vs. Custom Post Types (CPTs)
1. Current Approach Using Taxonomies:

• Currently, in PCForge, the PC components—such as Cases, Cooling, CPUs, Graphics, Memory, Motherboards, PSUs, and Storage—are organized as terms within taxonomies, rather than as Custom Post Types (CPTs). For example, in the CPUs taxonomy, we see terms like “AMD” acting as a parent term, with specific CPUs like Ryzen 5 5600X, Ryzen 7 5800X, and Ryzen 9 5900X listed as child terms.
• Each CPU term includes custom fields (e.g., Socket, Cores) using ACF fields of the “Text” type.

PCForge CPU Details (Field Group)
OC Forge Taxonomies

This structure raises several questions:

• Brand Representation: AMD, Intel, and other brands are currently set as parent terms within component taxonomies. However, brands are not strictly categories—they represent manufacturers. Designating AMD or Intel as parent terms within CPUs, rather than as brands, can be misleading and complicate organizational clarity. Typically, users expect brands to be a separate taxonomy or field to indicate manufacturers, not as hierarchical parents in a component category.
• Limited Scalability and Flexibility: The taxonomy structure for component categories appears limiting, especially when considering the need for specifications and compatibility filters. A CPT-based structure for each product category (such as CPUs, Motherboards, GPUs, etc.) would make data more manageable, with component-specific taxonomies and custom fields unique to each CPT. This change could enable better filtering and compatibility management, as each component could then be indexed, related, and filtered in more practical ways.

PCForge Graphics Taxonomy Terms
PCForge Motherboard Taxonomy Terms
PCForge Edit Motherboard Taxonomy Terms. MSI
PCForge Edit Motherboard Taxonomy Terms. B550 Tomahawk

2. Alternative Structure Using Custom Post Types (CPTs):

• Adopting CPTs for each product category would allow for a more intuitive structure and better scalability. By creating CPTs for categories like Cases, Cooling, CPUs, Graphics, etc., each could have dedicated taxonomies and custom fields, making it possible to implement unique filters and specifications relevant to each product type.
• With this setup, brands like AMD and Intel could be a separate taxonomy or a custom field within each CPT, offering greater flexibility in managing manufacturers. This structure could also simplify compatibility management, allowing for rules and filters that would prevent users from selecting incompatible components.

Compatibility and Builder Functionality

• At the moment, the PC builder isn’t working correctly when it comes to enforcing component compatibility. For instance, in the builder, I first selected the CPU field and chose “AMD.” This opened another field where I selected the specific CPU model, “Ryzen 5 5600X.” I then moved to the Motherboard field, where I selected “Asus,” which opened a field to choose the specific Asus motherboard. From there, I chose “Asus ROG Strix Z590-E Gaming WiFi.” These components are clearly incompatible, as the Z590 chipset only supports Intel CPUs, but the builder currently allows this incompatible pairing, which can mislead users and compromise the builder’s usability.
• Structuring component compatibility filters is crucial for a builder feature to deliver real value. Right now, without compatibility filters, there’s a risk of user error, which diminishes the reliability of the builder.

4. Challenges with Drop-Down Menus and Scalability:

• The drop-down menus in the current builder structure are manageable with a small selection of components (e.g., a few CPUs, motherboards, GPUs). However, in a real-world scenario where a comprehensive PC builder might handle thousands of components, these menus would become unwieldy. PCForge Builder
• A CPT-based structure, combined with compatibility filters, could better support a large-scale component database, and allow for more effective navigation, filtering, and component selection.

5. Seeking Clarification on Design Choices:
I acknowledge that I may be misunderstanding certain aspects of the builder’s structure, and I could be overlooking reasons for these specific design decisions. I would appreciate it if you could clarify the thinking behind this setup, particularly around the choice to organize components as terms in taxonomies instead of using Custom Post Types. Understanding the rationale behind this approach would be really helpful, as I’m keen to make the best use of the PCForge template for my project.

Offering Assistance
I genuinely love the PCForge concept, and I’d like to offer any support that could help improve it. I run a PC hardware store, so I’d be more than happy to provide compatible component data or any other details your team might need to refine the compatibility functionality or the component structure. I’m sure Tagdiv has the expertise to tackle compatibility logic, and I would be excited to see PCForge become a go-to WordPress solution for PC building.

Market Potential and Future Opportunities
I believe PCForge has the potential to be an industry leader if optimized to handle compatibility and larger datasets. Many users across forums frequently ask how to implement a WordPress-based PC builder similar to PCPartPicker, and no one has offered a concrete solution. Instead, recommendations typically include using CPTs. I know a good number of people purchase the Newspaper theme specifically for PCForge, and with further refinement, it could become the standard solution in WordPress for this need.

Thank you for considering this feedback, and please don’t hesitate to reach out if I can assist with any data or further insights. I look forward to seeing how PCForge evolves and to potentially using it as a core part of my project.

Best regards,

Thank you for the quick response and for clarifying the intention behind the prebuilt PCForge website!

I appreciate that the current setup is just an example, designed with a specific workflow in mind, and understand now why it’s structured this way. I also see the importance of setting up custom post types, taxonomies, and custom fields independently to avoid losing them if I uninstall the prebuilt website.

I do have a few follow-up questions to help ensure I’m moving in the right direction with creating a custom solution:

1. Compatibility Logic: I realize I’ve asked this question twice on the forum, so please feel free to delete the duplicate post here. Since compatibility between components isn’t included by default, are there any specific plugins or approaches you would recommend to implement compatibility filtering? For example, if I wanted to set compatibility rules so that only compatible CPUs and motherboards can be selected together, is there a specific method or workflow within Newspaper Theme that would work best?

2. Form Selector for Category Pages: Is there a way to make the form selector lead to a dedicated category page for each component type—like CPU, Graphics, Storage—where users could apply specific filters for each component category? For instance, after selecting a component, it would take the user to that category page to refine their options and then bring them back to the form to choose the next component. Any guidance on setting up this kind of structured flow would be helpful.

Thank you again for your help and the insights into best practices for building out my own component setup. I’m very excited to implement this and appreciate any further guidance you can provide!

Have a wonderful weekend as well!

Best.

Thank you for the clarification! I understand now that implementing compatibility between components and establishing relationships like the one I mentioned will require custom work.

Before I proceed with submitting a request for custom work, could you provide a rough idea or approach on how to implement the compatibility between components? I’m particularly interested in understanding how to create relationships between posts using a post object. I would appreciate any insights or general steps that could help me get started with this.

Thanks again for your help, and I look forward to your advice!

Best regards