Navigating the Magento Maze: Understanding Adobe Commerce, Open Source, and Fake Websites

The world of e-commerce platforms can be complex, and Magento is no exception. Once a standalone powerhouse, Magento is now part of the Adobe family, which has brought both significant changes and a fair amount of confusion. If you’re considering Magento for your online store, it’s crucial to understand the landscape, differentiate between the official versions, and watch out for misleading websites.

Adobe’s Acquisition: A Turning Point

In 2018, Adobe made a splash in the e-commerce market by acquiring Magento Commerce for a staggering $1.68 billion. This acquisition marked a significant shift, transforming Magento from a separate entity to a core component of the Adobe Experience Cloud. It also introduced two distinct “flavors” of Magento:

  • Adobe Commerce (Formerly Magento Commerce/Enterprise): This is the paid, commercial version, designed for medium to large businesses with complex needs. It comes with cloud hosting on Adobe’s infrastructure (with optional on-premise hosting), robust enterprise-level features, enhanced support, and access to Adobe’s suite of marketing and analytics tools. It operates on a subscription basis.
  • Adobe Commerce Open Source (Formerly Magento Open Source): This is the free, open-source version of Magento. While it provides the core e-commerce functionality, it requires more hands-on technical expertise and is primarily self-hosted.

The Open Source Question: Is Magento Still “Free”?

The core technology of Magento is still open-source, and it’s the very foundation upon which Adobe Commerce is built. This means that the base code is available under the Open Software License 3.0, allowing developers to use, modify, and distribute it without licensing fees. However, the “free” aspect comes with caveats:

  • Self-Hosting Costs: While the software itself is free, you’re responsible for hosting it on your own servers or with a hosting provider. This incurs costs for server space, bandwidth, and maintenance.
  • Extension/Plugin Costs: To extend functionality, you may need to purchase paid extensions or develop custom modules, which will also increase the overall cost of your setup.
  • Technical Resources: A significant amount of technical knowledge is required to maintain and update the open-source version of Magento. It often requires a development team.
  • Community Support: As the free version, you are limited to only community support.

Beware of Fake Websites: A Word of Caution

This is where things can get tricky. There are websites online that attempt to capitalize on the name “Magento Open Source” by presenting themselves as the official source for the free version. One such example is magento-opensource [dot] com. This site and others like it, are NOT official Magento or Adobe websites. They are third-party sites that could potentially mislead you or put your site at risk.

Here’s why you should avoid unofficial sources:

  • Security Risks: Downloads from unofficial sources could contain malware or modified code with vulnerabilities.
  • Outdated Software: You may end up with an outdated version of Magento that does not include the latest security patches and bug fixes.
  • Lack of Support: These sites don’t provide the same level of documentation, support, or access to the official community forums as official sources.
  • Misleading Information: Their content could be biased or misrepresent the features of Adobe Commerce Open Source.

Where to Find the Official Adobe Commerce Open Source

To ensure you’re getting the genuine, secure, and up-to-date Adobe Commerce Open Source software, always rely on the following:

Choosing the Right Path for Your Business

The choice between Adobe Commerce (paid) and Adobe Commerce Open Source (free) depends heavily on your needs:

  • Choose Adobe Commerce if: You’re a larger business that requires enterprise-level features, advanced marketing tools, cloud hosting, official support, and integration with the Adobe ecosystem.
  • Choose Adobe Commerce Open Source if: You have a smaller budget, a technically capable team, and you’re comfortable with self-hosting and community support.

The Bottom Line

Magento is a robust platform with a complex history, evolving from a standalone open-source option to a major component of Adobe’s enterprise offering. The key takeaways are:

  • Adobe owns Magento, which has two versions: the paid Adobe Commerce and the free, open-source Adobe Commerce Open Source.
  • The core technology is still open-source and available under the Open Software License 3.0, but does not come with all the features.
  • Be cautious of websites that claim to be the official source for the open-source version. Always rely on the official Adobe website or the official GitHub repository.
  • Assess your needs and technical capabilities before choosing between the commercial or open-source versions.

By understanding these key differences and verifying your sources, you’ll be better equipped to navigate the Magento ecosystem and make the right decision for your business.

You can check out other e-commerce website builders that may better suit you (and are a lot easier!) than Magento in our Choose Website Builder directory.

Posted in Magento | Tagged , , , , , , , | Leave a comment

When Giants Fall: What Movable Type’s Demise Teaches Us About WordPress’s Future

It’s hard to believe now, but there was a time when Movable Type dominated the blogging world. Before WordPress rose to prominence, Movable Type was the go-to platform for anyone who wanted a professional blogging experience. And yet, despite its early success, Movable Type’s legacy is now a cautionary tale—a warning about how quickly the tides can turn. As WordPress faces increasing scrutiny over its governance, licensing, and leadership, it’s worth asking: could WordPress follow the same path as Movable Type?

Let’s explore how Movable Type lost its throne, the safeguards WordPress has in place to avoid a similar fate, and what history teaches us about the dangers of corporate influence in open-source software.

The Rise and Fall of Movable Type

Launched in 2001 by Six Apart, Movable Type quickly became a favorite among bloggers. It offered powerful features, a customizable design, and robust functionality—a major upgrade from the primitive blogging tools available at the time. While not technically open-source, Movable Type allowed users access to its source code for personal use, creating the illusion of a free and open platform.
This illusion shattered in 2004, when Six Apart announced licensing changes for Movable Type 3.0. The new model introduced paid licenses for commercial and high-traffic users, sparking outrage among its community. Users who had built their blogs and businesses on Movable Type felt betrayed. Many migrated to a rising competitor: WordPress.

The backlash was swift and devastating. Within a few years, WordPress eclipsed Movable Type as the dominant blogging platform. Movable Type shifted focus to enterprise clients, but the damage was done. Today, Movable Type survives as a niche product, primarily in Japan, a shadow of its former self.

WordPress: The Untouchable King?

Unlike Movable Type, WordPress has always been open source, licensed under the GNU General Public License (GPL). This means:

  1. The Code Is Free: Anyone can use, modify, and redistribute WordPress’s code, for any purpose.
  2. Forking Is Allowed: If the community ever disagrees with the direction WordPress takes, they can fork the project and create their own version. In fact, this has already happened with projects like ClassicPress.
  3. No Forced Licensing Fees: Because of the GPL, WordPress cannot introduce licensing fees for its core software without violating the license.

These safeguards have made WordPress incredibly resilient. Even if Automattic—the company founded by WordPress co-creator Matt Mullenweg—decided to commercialize future versions, the community could simply fork the existing codebase and continue development independently.

But that doesn’t mean WordPress is immune to drama.

The WordPress Drama: Leadership and Community Tensions

Much of the recent controversy surrounding WordPress stems from its governance structure. While WordPress.org is technically managed by a global community, Automattic wields significant influence, as its founder, Matt Mullenweg, serves as the project’s lead developer. Critics argue that this creates a conflict of interest, as Automattic profits from commercial products like WordPress.com and WooCommerce.

Key Points of Contention:

  • Leadership Transparency: Many in the community feel that decision-making is concentrated in the hands of a few individuals, with limited input from contributors.
  • Monetization Concerns: While WordPress.org remains free, critics worry about the increasing commercialization of the ecosystem through Automattic’s paid services.
  • Plugin and Theme Ecosystem: Some developers feel that Automattic’s products receive preferential treatment, making it harder for independent developers to compete.

These issues have led some to question whether WordPress’s open-source model could ever be compromised.

Could WordPress Become the Next Movable Type?

The short answer is: highly unlikely. Here’s why:

1. The GPL License Protects the Core

Movable Type’s proprietary licensing model allowed Six Apart to enforce paid licenses and restrict forks. WordPress’s GPL license ensures that its core software remains free and open. Even if Automattic wanted to introduce licensing fees, it couldn’t legally prevent the community from continuing the project independently.

2. A Decentralized Community

WordPress is maintained by a massive global community of developers, designers, and users. While Automattic plays a significant role, it’s far from the only contributor. This decentralization makes it much harder for any one entity to radically change the project’s direction.

3. Revenue Through Services, Not Licenses

Automattic’s business model relies on offering premium services (e.g., WordPress.com hosting, WooCommerce extensions), not on charging for the WordPress software itself. This aligns with the open-source philosophy and avoids the pitfalls that doomed Movable Type.

Lessons from Movable Type’s Decline

Movable Type’s downfall offers valuable lessons for the WordPress community:

  1. Never Take Your Users for Granted: Movable Type’s licensing changes alienated its most loyal users, driving them to competitors. WordPress must prioritize community trust to maintain its dominance.
  2. Transparency Is Key: A lack of communication and transparency around major decisions eroded confidence in Movable Type. WordPress can avoid this by fostering open, inclusive governance.
  3. Embrace Open Source Fully: Movable Type’s proprietary model limited community involvement and stifled innovation. WordPress’s open-source model has been a major factor in its success and should remain central to its identity.

The Future of WordPress

While WordPress faces its share of challenges, its open-source foundation and vibrant community make it uniquely positioned to weather the storms. The lessons of Movable Type’s decline serve as a reminder of what can happen when trust is broken and corporate interests take precedence over community needs.

For WordPress to remain the king of open source content management, it must stay true to its roots: open-source freedom, community collaboration, and transparency. As long as those principles remain intact, WordPress is unlikely to suffer the same fate as Movable Type.

What Do You Think?

Is WordPress truly untouchable, or do you see cracks in the foundation? Share your thoughts in the comments below!

Posted in WordPress | Tagged , , , , , , , , , , , , | Leave a comment

WordPress: Challenges and Limitations of a Legacy Codebase

WordPress challenges, outdated code

WordPress has long been a dominant force in the world of content management systems, powering over 40% of websites worldwide. However, beneath its widespread adoption lies a legacy codebase that poses significant challenges for modern developers. From procedural programming practices to backwards compatibility constraints, this article explores the architectural, performance, and security hurdles faced by WordPress developers and website owners.

1. Legacy PHP Codebase

  • Procedural Programming: WordPress relies heavily on procedural programming, a paradigm that is less modular and harder to maintain compared to modern object-oriented programming (OOP). While OOP is partially adopted, much of the core code remains procedural.
  • Inconsistent Coding Practices: The codebase reflects contributions from thousands of developers over the years, resulting in a lack of uniformity in coding style, naming conventions, and design patterns.
  • Dependence on Older PHP Versions: Historically, WordPress maintained compatibility with older PHP versions to accommodate hosting providers. While newer versions are supported now, remnants of older syntax and practices persist.

2. Backwards Compatibility at All Costs

  • Deprecated Functions and Features: To ensure old themes and plugins don’t break, WordPress rarely removes deprecated functions or APIs, keeping unused or outdated code in the core.
  • Bloat: The need to maintain compatibility has led to excessive code and duplication, as newer features are often layered on top of old ones without removing or replacing outdated components.
  • Global Variables: WordPress heavily relies on global variables (like $wpdb and $post), which are convenient for backward compatibility but hinder modern, modular development.

3. Database Architecture Limitations

  • Single Database Table for Post Types (wp_posts): WordPress stores all content types—posts, pages, custom post types—in a single database table (wp_posts). This design simplifies some operations but becomes inefficient for large or complex websites due to table bloat and performance issues.
  • Meta Tables for Everything: WordPress relies on separate meta tables (wp_postmeta, wp_usermeta, etc.) to store additional data. These tables grow rapidly, and querying large datasets from them can lead to significant performance bottlenecks.
  • Lack of Relational Integrity: The database schema doesn’t enforce foreign key constraints, making it prone to data integrity issues.

4. Theme and Plugin System Complexity

  • Lack of Dependency Management: Themes and plugins often duplicate functionality because there’s no built-in dependency management. For example, multiple plugins might load their own versions of the same library, causing conflicts or redundancies.
  • Hooks and Filters Overhead: While the action and filter hooks system is flexible, it creates complexity and can lead to conflicts when themes and plugins use the same hooks. Debugging becomes increasingly difficult as hooks proliferate.
  • Inconsistent APIs: Over time, different APIs have been introduced (e.g., REST API, XML-RPC), but they lack uniformity in implementation, further complicating development.

5. Performance Challenges

  • Front-End Performance: WordPress’s templating system (the_content(), wp_head(), etc.) often outputs unnecessary elements, increasing page weight unless explicitly optimized by developers.
  • Query Performance: Outdated SQL queries and the reliance on meta tables lead to slow database queries, especially on large-scale websites.
  • Heavy Use of PHP for Rendering: Instead of adopting modern front-end technologies like React for server-side rendering (outside of Gutenberg), WordPress continues to rely on PHP for rendering pages, which is slower in high-traffic situations.

6. Security Vulnerabilities

  • Broad Attack Surface: The sheer size of the WordPress ecosystem—including core, themes, and plugins—creates a massive attack surface for hackers.
  • Untrusted Plugins and Themes: Many plugins and themes are poorly maintained, introducing vulnerabilities. The lack of strong code review for third-party extensions exacerbates the problem.
  • Legacy Code Exploits: Old code and APIs retained for backward compatibility may not adhere to modern security best practices, making them susceptible to exploits.

7. REST API Integration

  • While the REST API was introduced to modernize WordPress and support decoupled applications, its implementation has been criticized for being overly complex and poorly documented in places.
  • Some developers argue that the REST API feels like a bolt-on feature rather than a seamless integration with the rest of WordPress, leading to inconsistencies in usage.

8. Inflexible Core Features

  • Options Table Overuse: WordPress uses the wp_options table for storing all sorts of configuration data, ranging from small settings to large serialized arrays. This table can grow unwieldy over time, slowing down queries.
  • Customizer Limitations: The Customizer, while functional, is outdated compared to modern visual editors in terms of speed and usability.

9. Testing and Debugging Gaps

  • Insufficient Automated Testing: While WordPress core has a growing test suite, it still lacks comprehensive coverage for all scenarios, especially edge cases.
  • Poor Debugging Tools: Developers rely heavily on third-party tools or plugins for debugging, as WordPress doesn’t provide advanced built-in debugging capabilities beyond basic logging.

10. Gutenberg Editor Integration

  • Incomplete Transition: The introduction of Gutenberg (block editor) was a step toward modernization, but its integration with the old codebase feels fragmented. Developers often struggle to bridge the gap between the block editor and the legacy systems.
  • Backward Compatibility Issues: While Gutenberg aims to modernize content editing, it has introduced its own technical challenges and conflicts with themes and plugins designed for the classic editor.

While WordPress remains a powerful and versatile platform, its legacy architecture and backwards compatibility commitments often hinder modernization efforts. Developers face challenges ranging from inefficient database design to performance bottlenecks and security vulnerabilities. Addressing these issues would require a fundamental overhaul of its core systems, a move that may conflict with its ethos of broad compatibility. Nevertheless, recognizing these limitations is the first step toward optimizing WordPress for modern web development needs.

Another option to consider is finding a website builder that better aligns with your needs. Platforms like Shopify, Squarespace, or UltimateWB offer modern features and streamlined workflows without the legacy constraints of WordPress. For detailed reviews and comparisons, visit choosewebsitebuilder.com to explore the best options for your next project.

Posted in WordPress | Tagged , , , , , , , , , | Leave a comment

Forking WordPress: A Path to Stability or an Opportunity to Rebuild?

WordPress needs code rewrite

WordPress has been a very popular open source website builder, powering more than 40% of all websites globally. Its open-source nature, vast plugin ecosystem, and ease of use have made it the go-to choice for businesses, bloggers, and developers alike. However, the current turmoil within the WordPress community—ranging from leadership disputes to contentious decisions about the platform’s future—has left many questioning its stability.

For those concerned about these uncertainties, forking WordPress seems like an obvious solution. A fork offers the opportunity to step away from the drama, regain control, and create a stable version of the CMS that prioritizes user needs. Yet, while forking might seem like a quick fix, it raises a critical question: is it time to rewrite WordPress from the ground up instead?

Here’s why the debate over forking versus rewriting reveals deeper challenges within WordPress’s aging codebase.

Why Developers Are Considering a Fork

The WordPress community has faced mounting tension in recent years. Disagreements over the Gutenberg block editor, concerns about centralized decision-making within Automattic (the company behind WordPress), and questions about governance and licensing have created an atmosphere of instability. For businesses that rely on WordPress to power their websites, this turbulence can feel risky and unpredictable.

Forking WordPress offers an escape—a way to distance oneself from the drama while still leveraging the strengths of the platform. By creating an independent version, developers and businesses can take control of the CMS’s future, ensuring stability, security, and alignment with their unique goals. This is particularly attractive for those who depend on WordPress but feel disillusioned by the direction it’s heading.

However, forking WordPress is not without its challenges. It may provide temporary relief from community issues, but it does nothing to address the elephant in the room: WordPress’s outdated and bloated codebase.

The Outdated Codebase: A Hidden Liability

One of WordPress’s greatest strengths—its commitment to backward compatibility—is also one of its biggest weaknesses. Over the years, the platform has prioritized ensuring that older plugins and themes remain functional with new updates. While this approach has helped maintain WordPress’s vast ecosystem, it has also led to a codebase burdened by decades of technical debt.

The result?

  • Inefficient Architecture: WordPress’s core is built on older PHP paradigms and coding practices that were state-of-the-art in the mid-2000s but feel clunky and inefficient today. Its reliance on procedural programming rather than modern object-oriented design hampers scalability and maintainability.
  • Bloated Code: As new features have been added, old ones have rarely been removed. This commitment to compatibility has created a codebase that’s heavy and unnecessarily complex.
  • Security Vulnerabilities: While WordPress has a dedicated security team, the sheer size and complexity of its code make it difficult to address vulnerabilities effectively. The need to preserve legacy features increases the attack surface for potential threats.
  • Poor Developer Experience: Many developers find working with WordPress core frustrating due to outdated conventions, a lack of modularity, and inconsistent coding patterns. This can deter skilled developers from contributing to or building upon the platform.

The Case for a Complete Rewrite

Given these challenges, many developers argue that WordPress doesn’t just need to be forked—it needs to be rewritten. A rewrite would provide an opportunity to modernize the platform, eliminate legacy code, and create a CMS that is better equipped to handle the demands of modern web development.

Here’s what a rewritten WordPress could achieve:

  • Modern Architecture: Transitioning to object-oriented programming and adopting frameworks or design patterns that align with modern PHP standards would make the codebase cleaner, more modular, and easier to maintain.
  • Streamlined Performance: Removing legacy code and focusing on efficiency would result in faster page loads, reduced resource usage, and better scalability for large websites.
  • Improved Security: A simpler, more focused codebase would make it easier to identify and patch vulnerabilities, providing better protection for users.
  • Better Developer Experience: A modernized WordPress could attract a new wave of developers, offering cleaner APIs, better documentation, and a more intuitive structure for building plugins and themes.

Of course, rewriting WordPress is no small feat. The platform’s success is tied to its vast ecosystem of plugins, themes, and customizations—all of which would need to be re-evaluated or rebuilt for compatibility with a rewritten core. This challenge is monumental, but it could be the only way to address WordPress’s long-standing technical debt and create a more sustainable future for the CMS.

Why Forking Alone Falls Short

Forking WordPress might solve the immediate problem of escaping community drama, but it doesn’t address the underlying issues with the codebase itself. A fork still inherits all of WordPress’s inefficiencies and limitations, leaving developers to maintain a flawed foundation. Over time, the technical debt baked into the code could hinder the fork’s ability to evolve, creating the same scalability and performance challenges faced by the original platform.

Additionally, maintaining a forked version of WordPress requires significant resources. Fork creators must stay on top of security updates, manage compatibility with third-party plugins and themes, and address bugs—all without the benefit of WordPress’s large contributor community. Without a plan to rewrite and modernize the codebase, a fork risks becoming just as unwieldy as the original WordPress.

Stability Through Rebuilding

For developers and businesses seeking stability, forking WordPress may seem like the path of least resistance. But in reality, the platform’s aging codebase means that a true solution lies not in creating another version of WordPress but in reimagining it entirely. A complete rewrite may be a monumental challenge, but it’s also an opportunity to build a CMS that is faster, more secure, and better suited to the needs of modern websites.

Forking WordPress may provide a temporary reprieve from community drama, but for those with the vision and resources to tackle the bigger problem, a rewrite offers the chance to create a platform that’s not only stable but truly innovative.

While forking and rewriting WordPress are two drastic solutions, it’s important to remember there’s a whole world of website builders out there! If the WordPress drama and technical hurdles become too much, consider exploring alternative platforms that might better suit your needs. Whether you prioritize ease of use, a modern codebase, or specific features, there’s likely a website builder that’s a perfect fit. Check out your options and compare features at choosewebsitebuilder.com before making a decision.

Posted in WordPress | Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

WordPress Hacked: Why Your Site Still Feels Dirty & How to Recover

WordPress hacked

Introduction:

So, your WordPress site got hacked. It’s a nightmare scenario for any website owner, and unfortunately, it’s a very common one. After the initial panic, you’ve taken steps to remove the malware, restore from a backup, and maybe even hired a professional to help. Your site is back up and running, but… something doesn’t feel quite right. You might be feeling that your site is somehow “dirty” after the fact. This article delves into why you may feel that way and the lingering challenges that can impact your site’s security, code, and SEO performance.

The Lingering Distrust:

Even after a successful cleanup, it’s normal to feel a lingering sense of distrust. You might be asking yourself:

  • Did we get everything? Are there still hidden files or backdoors left behind by the hackers?
  • Could it happen again? Is the website as secure as it was before?
  • Has our reputation been damaged? How long will the effects of the hack linger?

This distrust stems from the nature of hacks. Hackers can be incredibly sneaky, leaving behind subtle code changes that are difficult to detect.

The Messy Code Reality

Cleaning up a hacked WordPress site often leaves behind a mess. Here’s why:

  • Injected Code: Hackers often inject malicious code into theme files, plugin files, database entries, or even core WordPress files. Even if the malware is removed, this injected code can be difficult to remove fully, and may still leave behind issues.
  • Compromised Plugins & Themes: Even a fully removed theme or plugin can be a point of infection. Compromised plugins or themes may have been altered, and should not be used, even if they were not the initial point of entry.
  • Database Mess: Hackers may also inject unwanted data into your database, making it bloated and disorganized. This can impact your site’s performance, cause database errors, and make cleanup incredibly messy.

Even when you do your best to manually clean up, it’s easy to miss hidden malware, making your site feel “dirty” and unstable. You may have issues where random posts appear, the layout looks odd, pages are slow to load, etc.

The SEO Nightmare and Spam:

A hacked WordPress site can wreak havoc on your SEO:

  • Spam Injections: Hackers often create spam pages or insert hidden spam links. These can damage your website’s reputation and hurt your search engine rankings.
  • Spam Posts & Comments: Spam and unauthorized posts may have been added to your site to help with the hackers goals, and these can linger and hurt your site.
  • Keyword Stuffing: Hackers can sometimes inject unwanted keywords into your website content or SEO settings. This could include keywords for unrelated or malicious purposes, which can damage SEO rankings and lower user experience.
  • Blacklisting: Your website may also have been added to blacklists by Google or other services, which prevents people from accessing the site, and greatly reduces rankings.
  • Google Penalties: Google may penalize your site for these issues, making it difficult for people to find you in search results.
  • Slow Loading Times: All of this added bloat can lead to slow loading pages, which is bad for SEO.

Cleaning up these SEO issues is often time-consuming and can feel like a never-ending battle. You may also have to disavow a large amount of bad links, using third party SEO tools.

Rebuilding Trust and Moving Forward:

Rebuilding trust in your site after a hack is difficult, but essential. Here’s what you should do:

  • Implement Robust Security: Install a strong security plugin, enable two-factor authentication, and consider using a web application firewall (WAF).
  • Regular Backups: Ensure you have regular, clean backups. A good backup will be important to restore your site quickly if something were to happen again.
  • Core, Theme, and Plugin Updates: Keep all software updated to patch vulnerabilities.
  • Regular Security Scans: Implement security scans and check to see if there are issues on your site regularly.
  • SEO Audits: Regularly audit your site for signs of spam, keyword stuffing, or compromised content.
  • Consider a Fresh Start: If your site is too messy, or you simply do not trust it any longer, you might consider starting fresh with a new installation of WordPress, and copying over only your content.
  • Be Proactive: Watch for suspicious activity, and learn from the experience, to reduce future risk.

Conclusion:

Recovering from a WordPress hack is not just about getting your site back online; it’s also about rebuilding trust in your website, cleaning up the mess, and restoring your SEO rankings. The feeling of a “dirty” site is a valid concern after a hack, and being aware of these lingering issues is essential for taking action and ensuring the long-term health of your website. By taking the right steps, you can strengthen your site’s security and regain the trust of your users and search engines.

Have you ever recovered from a WordPress hack? Share your experience in the comments below!

If you’re feeling unsure about your site’s security, reach out to a professional for help.

Posted in WordPress | Tagged , , , , , , , , , , , , | Leave a comment