On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • Peter Falkenberg Brown Reply #121, 11 years, 3 months ago
    Dear All,

    As a follow up, I checked out Drupal a bit today, and ran across this link:

    http://www.avenuewebmedia.com/high-profile-sites-run-drupal

    It states that FastCompany magazine uses Drupal with over 200,000 articles, and
    Popular Science uses Drupal with over 60,000 articles.

    Of course, I don’t know if those sites use Drupal’s CMS system, or if they
    customized it, as this thread has suggested one should do with MODx.
    I intend to find out smiley.

    I truly hope that MODx can become a "big-iron" CMS, able to handle the above numbers.
    If it can grow into that, I believe it will be even more successful.

    Peter
      Visit The Significato Journal ~ nectar for the soul ~ http://significatojournal.com
    • First, MODx is not Drupal, nor is it WordPress or Joomla! It is architected in a different way, for specific reasons. It works in a different way. I can create a MODx web site with 1 Resource that serves 1 million blog posts efficiently. It’s just a matter of choosing the right solution to the challenge at hand. Creating a Resource for each one of those 1 million blog posts would never be the right solution in MODx though. It might work in WordPress because WordPress is designed to handle large volumes of specific kinds of web content, namely blog posts; not just any kind of web content.

      Second, MODx 2.0 (aka Revo) can already theoretically handle unlimited Resources. And we will of course be improving the system based on real world usage as development and releases continue. But you can simply turn off the caching of context settings (cache_context_settings). You will lose baseline performance on any requests that use non-cacheable Elements, but you will gain the ability to handle a larger volume of Resources limited only by your physical server limits; no monolithic cache file of all the Resources in the Context. But there is always a complex tradeoff between volume and efficiency, and I like to be prepared for unexpected volume from the beginning. In that sense, I don’t think this really is about "Enterprise App Development" as much as it is simply about designing for scalability and reusability, of both your presentation logic and your raw content (or data).

      Regardless, I will never see data as web content. Data is raw content that is representing something specific. Whether that be in a RDBMS, or accessible from a web service, or in a schema-less NoSQL database makes no difference. Web content is a specific "view" of that data; formatted in some way for delivery on the web. If you have two different ways you want to present 30,000 items, are you going to create and manage 60,000 Resources or are you going to build two views into 30,000 pieces of data? And besides, IMO, you simply do not manage data in the same way you do web content. Consider a blog with the ease of use of WordPress. The bloggers don’t want to see a tree of the entire website necessarily; if you can now create a unique and custom UI for managing and writing blog entries and deploy that over and over again inside any MODx site, which still provides the cool site tree for the rest of the web site that is not so bloggy, wouldn’t that be ideal? That is what we are talking about. Do you want your web catalog inventory managed in the same way as your marketing web pages? And do you want that product data to be handled in the same way as your web pages? MODx Resources are treated in specific ways to optimize them for delivering web content, not for being collected and summarized in 10 different formats across the web site, made available as web services, etc. etc.

      Anyway, I’ll stop, but the intention of MODx Revolution is to provide a framework to build a powerful toolkit of reusable components for constructing and organizing anything that is going to be presented on the web. It is one part PHP framework and one part web CMS. I think as you see new features and Extras become available for this truly unique product, you will start to understand that we all have the same goal in mind here: an easily extensible and customizable web platform that provides creative freedom without sacrificing power and scalability. And as more MODx developers create solutions for specific web problems, you’ll be able to let MODx handle your yearning for the infinite without having to code a CMS within the CMS.
      • Peter Falkenberg Brown Reply #123, 11 years, 3 months ago
        Dear Jason,

        Thank you for your comments; I appreciate them.

        Your explanation makes sense, and certainly MODx Revolution looks like it will be a very powerful product. I believe that for me, my questions were based on a misunderstanding of what MODx is. I understand the difference between data and presentation; that’s important.

        I was coming to MODx from a custom built CMS built on top of a framework application I built in Perl, so I understand the value of what you’re talking about.

        I believe that MODx would be well served with just a wee bit more upfront documentation about these issues, so that the limitations on one hand and the power on the other are presented in a more comprehensive way.

        I like powerful programming tools and frameworks, and they’re a joy to use -- when one wants to take the time to embark on that level of programming. My expectations were that MODx would work out of the box as a CMS -- and it does it beautifully -- except for the resource limitations you’ve discussed.

        So... I think it’s important to include notes on this right up front, so that people will realize the boundaries more clearly. I took the 5,000 resource limit literally, and did not plan to take the time to program a CMS on top of MODx, as you’ve described. I’m not against the idea -- I had simply assumed it wouldn’t be necessary, and didn’t want to invest many, many hours in that process (having already done that once before).

        I’ll consider installing MODx Revo, to see how I like that.

        Thanks for your clarifications!

        Peter
          Visit The Significato Journal ~ nectar for the soul ~ http://significatojournal.com
        • understand that we all have the same goal in mind here
          Absolutely, the flexibility allows problems to be approached in so many different ways the hardest part becomes picking the best one.
            Use MODx, or the cat gets it!
          • OpenGeek,

            Thanks for your words...i recon MODx is not like any other CMS / blog system for that matter. Personally i hate systems like drupal/wordpress and MODx doesn’t even compare to those. It’s just too different, it’s like comparing a PC with a Mac (pun intended).

            It would be a shame to sacrifice the great caching of MODx just so we can use resources...i don’t think that’s the solution. You made your point clear...resources are for displaying web-content and not for holding raw data. I did not know this, so this changes my perspective.

            I still have the utmost respect for the design philosophy of MODx. I love the way it’s thought through!
              Follow me on twitter: @b03tz
              Follow SCHERP Ontwikkeling on twitter: @scherpontwikkel
              CodeMaster
            • The only problem we face now is how to let the client use resources and (in our case) webshop items and order them together in a menu (wayfinder) or in a listing where maybe we have 50 products from the custom db and we have 2 resources with extra information that we also like to be in the same list.

              how could a client sort that in a good way? and easy way?
                follow me on twitter: @dimmy01
              • Quote from: OpenGeek at Jul 09, 2010, 11:48 PM

                First, MODx is not Drupal, nor is it WordPress or Joomla! It is architected in a different way, for specific reasons. It works in a different way. I can create a MODx web site with 1 Resource that serves 1 million blog posts efficiently. It’s just a matter of choosing the right solution to the challenge at hand. Creating a Resource for each one of those 1 million blog posts would never be the right solution in MODx though. It might work in WordPress because WordPress is designed to handle large volumes of specific kinds of web content, namely blog posts; not just any kind of web content.

                Second, MODx 2.0 (aka Revo) can already theoretically handle unlimited Resources. And we will of course be improving the system based on real world usage as development and releases continue. But you can simply turn off the caching of context settings (cache_context_settings). You will lose baseline performance on any requests that use non-cacheable Elements, but you will gain the ability to handle a larger volume of Resources limited only by your physical server limits; no monolithic cache file of all the Resources in the Context. But there is always a complex tradeoff between volume and efficiency, and I like to be prepared for unexpected volume from the beginning. In that sense, I don’t think this really is about "Enterprise App Development" as much as it is simply about designing for scalability and reusability, of both your presentation logic and your raw content (or data).

                Regardless, I will never see data as web content. Data is raw content that is representing something specific. Whether that be in a RDBMS, or accessible from a web service, or in a schema-less NoSQL database makes no difference. Web content is a specific "view" of that data; formatted in some way for delivery on the web. If you have two different ways you want to present 30,000 items, are you going to create and manage 60,000 Resources or are you going to build two views into 30,000 pieces of data? And besides, IMO, you simply do not manage data in the same way you do web content. Consider a blog with the ease of use of WordPress. The bloggers don’t want to see a tree of the entire website necessarily; if you can now create a unique and custom UI for managing and writing blog entries and deploy that over and over again inside any MODx site, which still provides the cool site tree for the rest of the web site that is not so bloggy, wouldn’t that be ideal? That is what we are talking about. Do you want your web catalog inventory managed in the same way as your marketing web pages? And do you want that product data to be handled in the same way as your web pages? MODx Resources are treated in specific ways to optimize them for delivering web content, not for being collected and summarized in 10 different formats across the web site, made available as web services, etc. etc.

                Anyway, I’ll stop, but the intention of MODx Revolution is to provide a framework to build a powerful toolkit of reusable components for constructing and organizing anything that is going to be presented on the web. It is one part PHP framework and one part web CMS. I think as you see new features and Extras become available for this truly unique product, you will start to understand that we all have the same goal in mind here: an easily extensible and customizable web platform that provides creative freedom without sacrificing power and scalability. And as more MODx developers create solutions for specific web problems, you’ll be able to let MODx handle your yearning for the infinite without having to code a CMS within the CMS.

                First of all, thanks for this insightful comment. Reading this i was curious what you’re take is on the new ’Creating a Blog’ tutorial:
                http://svn.modxcms.com/docs/display/revolution/Creating+a+Blog+in+MODx+Revolution

                I really like the tutorial and i could easily see myself using this kind of setup for blog/news type of content. It’s pretty flexible and powerful stuff but it is a resource based approach. I think you use a similar approach on your own site. Could you shed some light on when en why you would choose for the CMP (custom manager page) based approach?
                • Quote from: SiNNuT at Jul 16, 2010, 09:43 PM

                  First of all, thanks for this insightful comment. Reading this i was curious what you’re take is on the new ’Creating a Blog’ tutorial:
                  http://svn.modxcms.com/docs/display/revolution/Creating+a+Blog+in+MODx+Revolution

                  I really like the tutorial and i could easily see myself using this kind of setup for blog/news type of content. It’s pretty flexible and powerful stuff but it is a resource based approach. I think you use a similar approach on your own site. Could you shed some light on when en why you would choose for the CMP (custom manager page) based approach?
                  When the scalability, performance, and/or volume of content in your requirements demand it. FWIW, I don’t write a large volume of blog/news posts, nor did I make my site easy for a client with little web publishing knowledge to manage; so I chose the Resource-based approach because a) it was quick and easy, b) an ideal Blogging component that uses a custom Resource class has not yet been realized yet and I needed my site up now, and c) the scale of my site does not demand using a dedicated blogging component that partitions it’s content away from the Resources.

                  I think this will all become clearer as we get past MODx Revolution’s public launch and start to focus on the Extras that solve specific problems in a healthy variety of ways.
                  • Quote from: OpenGeek at Jul 17, 2010, 06:40 PM

                    Quote from: SiNNuT at Jul 16, 2010, 09:43 PM

                    First of all, thanks for this insightful comment. Reading this i was curious what you’re take is on the new ’Creating a Blog’ tutorial:
                    http://svn.modxcms.com/docs/display/revolution/Creating+a+Blog+in+MODx+Revolution

                    I really like the tutorial and i could easily see myself using this kind of setup for blog/news type of content. It’s pretty flexible and powerful stuff but it is a resource based approach. I think you use a similar approach on your own site. Could you shed some light on when en why you would choose for the CMP (custom manager page) based approach?
                    When the scalability, performance, and/or volume of content in your requirements demand it. FWIW, I don’t write a large volume of blog/news posts, nor did I make my site easy for a client with little web publishing knowledge to manage; so I chose the Resource-based approach because a) it was quick and easy, b) an ideal Blogging component that uses a custom Resource class has not yet been realized yet and I needed my site up now, and c) the scale of my site does not demand using a dedicated blogging component that partitions it’s content away from the Resources.

                    I think this will all become clearer as we get past MODx Revolution’s public launch and start to focus on the Extras that solve specific problems in a healthy variety of ways.

                    Once again, thx for the reply. I guess i needed a little bit of reassurance. I’m running a couple of smallish sites in the non-profit sector and sports industry. At the moment they are Evo based and i’m gonna start migrating to Revo soon. Seeing that the ’news sections’ average on about 25 to 50 posts a year i think i’m going for the resource-based approach as well. The clients are already familiar with Evo so with a little guidance it won’t be a problem for them publishing using Resources.
                    • At up to 50 new resources per year—or even quadruple that—you’ve honestly got about a decade’s worth of headroom before you need to start worrying. It may not be technically ideal, but it’s entirely doable and hardware gains in IO will more than make up for any inefficiencies you probably could cook up.
                        Ryan Thrash, MODX Co-Founder
                        Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me