We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 20413
    • 2,877 Posts
    This is cool! cool
    Using TVs for tags - Could you set the tags from front-end?

    I am doing it this way
    http://modxcms.com/forums/index.php/topic,5814.msg232384.html#msg232384
      @hawproductions | http://mrhaw.com/

      Infograph: MODX Advanced Install in 7 steps:
      http://forums.modx.com/thread/96954/infograph-modx-advanced-install-in-7-steps

      Recap: Portland, OR (PDX) MODX CMS Meetup, Oct 6, 2015. US Bancorp Tower
      http://mrhaw.com/modx_portland_oregon_pdx_modx_cms_meetup_oct_2015_us_bancorp_tower
      • 16278
      • 928 Posts
      pkBlog version 1.1.0 is now available (zip file in original post updated). This version adds publication date ranges and better status indication.

      The standard pub_date field is used as the "display from" field, and has a custom TV pkDateTo so you don’t have to do any arithmetic for an expiry date - you set the date range as the first and last days the item is to be displayed, and the unpub_date is set to be one day after pkDateTo.

      The post management screen now has a button at the top linking to the Create/Edit Post page. I still have some work to do to add Edit buttons to published posts, and navigation in the admin zone for logged-in editors.

      Several elements (I use the term loosely!) have been added to implement status flagging in the post management screen, and the status line in the editing form for posts has been pimped. There is a new Ditto extender that checks the preview flag TV, "published" field and publication dates vs current date, and returns an alphabetic status code. This can be displayed with a [+status+] placeholder. A custom PHx modifier takes the status code and colours the cells containing the status flag, item date and publication dates by setting CSS classes, with a basic "red, amber, green" scheme for expired, pending and live items, plus colours for drafts (items still in preview mode) and for manually unpublished items (or unrecognized status). I think this will all work without having to install PHx as a plugin, using Ditto’s own PHx library - have to test locally with PHx plugin disabled, as I use it for other things on the Pogwatch site.

      It would be interesting to hear if anyone has managed to install a blog from the zip files, or what was lacking if the attempt failed.

      @mrhaw: tags are already editable in the front end. Your tagging TV (pwTags, in my case) can be a checkbox or radio button set. The optionsbuilder class creates the HTML code for a fieldset with the options within it, setting up input tags according to defaults and stored values. I considered reassigning redundant fields for tagging when I first wanted to enhance the NewsPublisher-based blog, but I think it is bad practice: shocked
      - you may realize at some point the field is not as redundant as you thought
      - you’ll always come to a point where you need one more field than the number of "spares" available
      - you can’t choose the names of the fields, and the native names can be misleading. (I used to work with a news editing system that had its origins in a mainframe. You had to know the history of the organization and of the system to understand why certain UK news agency items were marked as coming from Berlin!)

      laugh KP
        • 1343 ☆ A M B ☆
        • 2,213 Posts
        This looks very promising and I look forward to testing it on a few sites in the near future. I do have one question tho... Are you going to add the ability to interact with custom TVs?

        On one of my sites I use a TV to add mp3 files for a radio system and it would be amazing if the other users could add the mp3 without my interaction.

        Keep up the good work!
          Patrick | Server Wrangler
          About Me: Website | Tweets |  MODX Hosting
          • 16183
          • 1,390 Posts
          Experience installing and using pkBlog 1.1.0.

          Wow! Good job Keith. This is really nice and creates lots of nice possibilities. Thanks for your great effort. I have a "few" observations below.

          =========================================
          My test environment

          Installed in MODx Evo 1.0
          Server environment
          Apache 2.2
          MySQL 5.1.37
          PHP 5.3
          FF 3.0
          Linux Mint Gloria x64

          ========================================
          Installation:

          This went fine without a hitch. Thank you for the instructions.

          =============================================
          Once installed, it has that feel of being easy to use, nothing complicated, which is good. My experience so far.....

          Usage

          1. pwBlogPostTemplate code: There is

          <hr  class="clearer"/>


          - Typo? What class is it referring to?
          - what file is it in? I couldn’t find it in forms.css

          2. Creating Blog Posts (documents):

          - When I preview a post (without first clicking publish) the post is still created in modx, but it is unpublished. Should it not only be created when I hit publish?

          - If I preview, the post is created, if I hit back button and click publish, it results in two documents being created; once when I hit preview and second when I hit publish

          3. When I create and publish a post, no template is assigned to it

          4. Following on from the above point, if not template is assigned, it follows that no tags are set, or am I missing something? I am referring to pwTags. By the way, I created all the TVs as described in pkBlog-tvs.html

          5. Manage blog posts:

          - I tried deleting posts but the posts were not deleted. The confirm deletion text didn’t come up. Maybe I missed a step? Was there more to it? I used the form on your site for "Managing Blog Post".

          - Using the form on your site for Managing Blog Post, in this code
          <form method="post" action="/admin/post.html" id="addItem"> 
          what should I use as the value of action?

          =============================
          Documentation

          Good effort on the instructions. May I suggest the following?

          1. Ditto: The installation doesn’t tell the "newbie" what to do if they already have Ditto installed. Should they overwrite files or not? This is important since, they might think they already have ditto and not copy this file. Problem is, it includes a custom extender needed by pkBlog.

          2. Jot: Shouldn’t Jot be part of the package? if not, maybe good to include this information in the installation guide that it is optional and if the user wants it, they need to install it themselves.

          3. Ditto tpl chunks: It may be good to state that when creating the chunks for Ditto chunks (blog.first.tpl, they shouldn’t use custom names but instead use the file names of the included .txt files since these are referenced in the code.

          4. Ditto tpl chunks: This text in the documentation "(Adjust the document IDs in links to match your site)" probably needs better explanation? The question one would ask is what documents on my site should they match? What will be the role of these documents?. How many documents need to be created? This will also help in naming the documents. For instance:

          5.Ditto tpl chunks: You have the following code:
          <form action="/[~686~]" method="post">
          <input type="hidden" name="docId" value="[+id+]" />
          <input type="hidden" name="tags" value="[+pwTags+]" />
          <input type="hidden" name="returnId" value = "685" />
          


          Is the 685 a typo? or is that a different document from 686?

          6. It may be an idea to tell the user if they wish to use form.css, where to upload that? The info could even be "upload form.css anyway you wish, as long as you reference it correctly in your MODx website template..blah blah"

          7. I was a bit confused after creating the TVs as described in pkBlog-tvs.html. Instinctively I though OK, where do I reference the TVS in my documents/templates so that they can be visible in the front-end. However, I noticed you already have these being called in the code you have provided. I was just thinking it may be good to add this info to the install instructions, i.e. once the user has created the TVS, they don’t need to do reference them in their templates/documents since that’s already taken care of.

          8. Apart from what is on your blog, I found no instructions for calling the blog, for instance.
          [!PubKitBlog? &folder=`2` &postid=`2` &template=`pwBlogPost` &rtcontent=`pkRichContent` &formtpl=`@FILE:blog` &delimiter=`,` !]
          


          Maybe an example should be included in the install guide? Hmm, it is now sounding more of user guide than an installation guide smiley

          9. pwBlogPostTemplate: I found no explanation of what the below does (i.e. the code) but I figured it was the comments template.

          "Create your blog post site template and paste in the text for the main part of the body from pwBlogPostTemplate.txt"

          - In addition, the code has the [#content] tag; It may be good to tell newbies not to duplicate that tag if they already have it in their MODx templates.

          10.pubKitBlog.snippet:

          &folder - folder id where comments are stored

          - This confused me. Are these jot comments or the posts themselves you are referring to? When creating new posts I found that the value I gave &folder would become the post’s parent/container/folder. Please clarify.

          - If &folder refers to the parent folder of the post being created, maybe it is good to point out (especially for newbies) that &folder=`0 would create a post just below the root.

          11. Manage blog posts: Maybe need to add to the documentation what you have on your site under "Management overview for pkBlog posts". i.e. the form, the Ditto call, etc I didn’t find this info in the documentation.

          =================================
          Wishlist

          I know these can be time consuming/difficult. May I suggest....

          - It would be good to give the user a feedback after posting? "Success blah blah, etc"

          - A back button would be nice after previewing a post you want to publish. Or maybe some instruction "click the back arrow in your browser to go back to the editing page, blah blah"

          - Would it be possible to set a template for the document when creating it?

          - And now for the biggie. I am sure you’ve read forum posts about the lack of a MODx blog addon. You might also have read posts about the disadvantages of using documents as blog posts, e.g. "what if I have 1000 posts?", etc. Maybe I am being naive here, but for a more robust blog experience, would it be possible to modify the code so that instead of being documents, the posts would actually be inserted into the database? I know it’s a lot of work though wink but I had to ask.

          -----------------------------------------------------
          Thank you very much for this brilliant kit.

          cheers/k
            • 7155
            • 160 Posts
            kongondo, I have to say you are the bestest user in whole wide modx world. your feedback is very useful and informative to any developer.

            <brainstorm>
            on your last point about the database vs document approach.

            Being relatively new to MODx development(slightly over a year) and still getting to grips with its power...

            I think most module/snippet developers have a difficult time deciding on going the database route(i.e no referrence or linkage to MODx documents for snippet-data) OR the document route. Taking the document route would mean easier access to very powerful and useful tools like Ditto,Jot..etc. If one takes the database route, i.e. no linkage to documents, then it means you would have to code smart and probably hard to make your data entities accessible to Ditto and others...without overwhelming that document tree. (is this where concern also lies?)

            I have thought about it too and thought maybe if one creates an unpublished document associated with a data item used by a snippet or module, then one can take full advantage of Ditto and others. But how would that affect viewing the items if they are unpublished documents?

            I also thought we should have an extra field or enum in some future MODx version(s), that would allow a document to be either "normal" or "data item". Default would be normal. If it is a "data item", then snippets and modules can relate or link their data to the document, and perhaps it could also have an option to display or not display it in the document tree.
            </brainstorm>

            will try out pkBlog, by the way
              • 16278
              • 928 Posts
              Thanks for the feedback, it is appreciated.

              Sadly no chance to take things further today (pesky income tax return) , but I should address a couple of the points raised before I drag myself off to bed:

              <hr class="clearer"/> is defined as .clearer {clear:both;} in my general site template. It’s a standard class in my CSS to resolve the problem when block elements have no height. (See e.g. http://www.positioniseverything.net/easyclearing.html)
              When I create and publish a post, no template is assigned to it
              Then something is wrong! If you have set the parameter &template=`pwBlogPost` and you have a template of that name, that’s the template that a post should have once published, thanks to Docmanager (line 202 in v1.1.0)
              $doc->SetTemplate($template);


              pwTags needs to be assigned to the template used in editing and the template for posts, of course. I realize it is hard-coded by this name into the snippet; it needs to made into a parameter. That might also help with other questions about web user access to template variables in general.

              The zipped documentation should describe what documents are needed as an operating minimum (the blog page, the admin login, the post management and the post editing page) and the content of snippet calls in them. Maybe some kind of map or inventory format, maybe generated from a spreadsheet. I used something along those lines to keep track of things at one stage of the project.

              Preview: A simple rule would read: DON’T USE BACK!!! To return to the editing form, use the Edit button, which generates a POST request with all the necessary data. Perhaps the Back button can be manipulated using Javascript to do nothing, to print an Alert or to do the same as the Edit button. As things stand, you will get duplication if you use Back, because the form gets nothing in the REQUEST variable so starts working on a new document, while the browser kindly fills in the fields from its cache, I think. But look on the bright side: maybe someone out there is desperate for some form of versioning? At least it is non-destructive, and you can continue editing and delete the unwanted earlier version.

              Similarly with a document being created when you ask for a preview. I’ve been editing a site using a predecessor of PubKit on a non-MODx site for a while now, and often find it would be handy to have a way of setting a draft aside to finish it later. Exiting the Preview screen without hitting any of its buttons (or Back, of course) does, in effect, create a stored draft. It’s not hidden away in the darkest recesses of the system, it is there with a clear status in the Manage Posts screen, with invitations to continue editing or delete it. And creating the preview document alongside the published ones, with its preview flag and unpublished status, makes it easy to handle with an alternative Ditto config. Hope this doesn’t shatter anyone’s MVC paradigm!

              Manage Posts: Delete should work. Maybe this has to do with the other question, about the form’s action attribute. "post.html" is the alias of my Edit Post document, and the Add, Delete and Edit links feed it data from the hidden fields. Delete goes through two stages - first the item’s title and headline are extracted to be presented in the delete confirmation form for unambiguous confirmation, then confirmation is fed back to the form to put it into effect.

              This destination, and several others where I’ve used the document IDs from my own site, need to be mapped explicitly so people can adjust them to suit their own site. I think I should try to give all such links as document aliases rather than IDs, so the relevant documents can be picked out clearly on a map, and for error avoidance.

              Last note for today:
              &folder - folder id where comments are stored
              is another unfortunate carryover from the NewsPublisher past. That should read "ID of folder where blog posts are stored", i.e. it’s their parent. Jot comments are stored in the database, and I’m pretty sure Jot is already part of the standard distribution up to and including MODx 1.0.

              More soon! laugh KP
                • 1751
                • 57 Posts
                Hi
                Thanks so much for developing and sharing this!
                I’m struggling with the setup though and wonder if someone can help please?
                When a new post is created, it uses the site default template from the config page in the manager - this is set in the PubKitBlog snippet under get template
                // get template
                $template = isset($template) ? $template : $modx->config['default_template'];
                .
                I would like to use a different template, which I have called Blog, but I can’t figure out how to set this...

                Anni
                  • 16183
                  • 1,390 Posts
                  Anni,

                  I believe it should be
                  [!PubKitBlog? &template=`Blog`....!]

                  Quote from the snippet code (pubKitBlog.Snippet)
                  &template - name of template to use for news post

                  cheers/k
                    • 1751
                    • 57 Posts
                    Thanks,
                    I did try that, it works without friendly urls, but with them, it removes the style sheet!
                    ie if I go to www.domain.com/index.php?id=50 it works fine, but if I go to www.domain.com/blog/40-test.html no style sheets are applied...
                    I thought I must be doing something wrong as a result, but now you’ve confirmed it should be that, it must be caused by something else...
                    I may just try removing Friendly alias paths and see if that helps.....

                    Anni
                      • 16183
                      • 1,390 Posts
                      @Keith,

                      Thx for the feedback. New posts are being assigned the correct template...twas sloppiness on my part; forgot to change the value of &template.

                      Still no joy with deleting posts. Nothing happens and posts are not deleted. And now the new posts are not listed in the manage posts page. If you get time, I would appreciate a step by step guide for this bit? Thx.

                      cheers/k