We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 13736
    • 345 Posts
    Let me add something else to the Version Control plans.

    I think we also need future version control or "review before publish" system. I envision that we would have the history resource/chunk/snippet, a "live" resource/chunk/snippet and then a "waiting" resource/chunk/snippet. At time of publishing, the "live" and "waiting" would be exact duplicates. However one could only edit the "waiting".

    The "waiting" version could be approved in which case the "live" copy would become a history version and the "waiting" would be duplicated to create a new "waiting" copy while itself becoming the new "live" resource/chunk/snippet.
    OR
    The "waiting" version could be rejected in which case it would be flushed and rebuilt from the current "live" version.
      • 26903
      • 1,336 Posts
      Yes, what we actually need before we attempt to code any of this is a process spec of what versioning will do, its such a large area, everyone has different ideas on how things it should be done and what its exact scope is.
        Use MODx, or the cat gets it!
      • I actually already have it implemented in the original Revolution prototype, FWIW; you just can’t haz it until everyone is using the OO API instead of direct SQL to access content. wink

        Having the ability to track diffs and rebuild versions baseline to a defined HEAD pointer is all possible, and you will be able to create all kinds of cool mechanisms for storing diffs that are not yet revealed by the HEAD pointer. This will make true draft save and preview before publish capabilities possible, as well as allowing an infinite variety of statuses for any publishing workflow.

        Also, the implementation will be wrapped into changes that will also allow custom content fields to be attached directly to Resources (site_content table will no longer have any content that could be localizable), as well as provide for cultural-specific content to be stored and accessed per Element.
        cool
          • 13736
          • 345 Posts
          What is the OO API that needs to be used and if it was in the original prototype what caused it to be withheld from the first release?
          • Quote from: Pixel at Nov 26, 2010, 04:38 AM

            What is the OO API that needs to be used and if it was in the original prototype what caused it to be withheld from the first release?
            The MODx Revolution API; the 2.0 release did not change the table structure to ease the pain of migrating custom code from Evolution releases. One of the primary reasons for the development of Revolution was to provide a foundation for being able to begin changing the underlying table structures to get from where MODx is to where we want it to be without breaking components every time we do it.

            For example, many components in Evolution directly query columns of the modx_site_content table; here is Ditto getting TV content for instance:
            <?php
            		$query = "SELECT stv.name,stc.tmplvarid,stc.contentid,stv.type,stv.display,stv.display_params,stc.value";
            		$query .= " FROM ".$tb1." stc LEFT JOIN ".$tb2." stv ON stv.id=stc.tmplvarid ";
            		$query .= " WHERE stv.name='".$tvname."' AND stc.contentid IN (".implode($docIDs,",").") ORDER BY stc.contentid ASC;";
            		$rs = $modx->db->query($query);
            		$tot = $modx->db->getRecordCount($rs);
            ?>

            If we were to move the actual content out of the value column, and reference say, an external content table with versioning, and perhaps cultural specific copies for localization, this becomes invalid.

            But, in Revolution this can handled much differently via the OO API it presents:
            <?php
            foreach ($collection as $resourceId => $resource) {
                $tvs = array();
                if (!empty($includeTVs)) {
                    $templateVars =& $resource->getMany('TemplateVars');
                    foreach ($templateVars as $tvId => $templateVar) {
                        $tvs[$tvPrefix . $templateVar->get('name')] = !empty($processTVs) ? $templateVar->renderOutput($resource->get('id')) : $templateVar->get('value');
                    }
                }
                // etc, etc, etc
            }
            ?>

            And though we may be referencing what appear to be columns in the table still, e.g. $templateVar->get(’value’), those are actually fields of an object now accessed by a function, which can be set from any source, not just directly from table columns. Thus the new way of working with MODx core data as objects, provides abstraction for providing better backwards compatibility. Not to mention it also provides abstraction from database engines, so we can port the application easily to other RDBMS’s than MySQL.
              • 26903
              • 1,336 Posts
              Could we not then create a branch in git that removes everything that is currently marked as ’deprecated’ or ’to be deprecated’ from the MODx API? I know for a fact that some of the code I’ve ported from Evolution uses these calls, new code I write doesn’t(in the main!), it would be interesting to install packages into this and see what breaks, hence forcing a rewrite of said code. I think this would be of value sooner rather than later.
                Use MODx, or the cat gets it!
              • Quote from: shamblett at Nov 26, 2010, 08:23 PM

                Could we not then create a branch in git that removes everything that is currently marked as ’deprecated’ or ’to be deprecated’ from the MODx API? I know for a fact that some of the code I’ve ported from Evolution uses these calls, new code I write doesn’t(in the main!), it would be interesting to install packages into this and see what breaks, hence forcing a rewrite of said code. I think this would be of value sooner rather than later.
                2.0.5 is the last scheduled release of 2.0; once that release branch is created, the develop branch will represent next scheduled release which is 2.1. One of the first tasks for 2.1 will be removing the methods deprecated in 2.0. We’re almost there.
                  • 26903
                  • 1,336 Posts
                  Ok, sounds good.
                    Use MODx, or the cat gets it!
                    • 33657
                    • 128 Posts
                    bump? where on the roadmap is this??? not having version control is pretty terrible... i am convincing customers to use modx over wordpress but then I have to tell them that if they screw something up we have to restore the database... so basically they are backing up a database every day (server backup) and developing on a dev mirrored modx site so they dont screw up production.. thats not a very good use of resources... i'd much rather have a history built in and they can just click restore on any chunk, snippet, template, template variable, etc.. why can't we just make a copy of every thing and store it in a seperate table? file size isn't a huge issue and maybe we can prune it after 30 versions?
                      • 33974
                      • 156 Posts
                      Mark Hamstra is currently developing a stable version of his addon VersionX which allows to have versioned resources including TVs. This is the first step to have versioned content.

                      Additionally there will be some kind of basic versioning in upcoming releases I think. It's not native but…
                      And finally native versioning is on the roadmap for MODX 3.0. It's a bit of time until release but finally it will come natively.