We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22815
    • 1,097 Posts
    If your site works with intentional fakedirs, it should work with a false fakedir. The trick is to have a baseurl in your CSS reference (often this is achieved by setting base href).

    Quote from: milicicd at Sep 16, 2006, 04:13 PM

    One of the important notes in first post says:

    * Don’t change the manager theme.

    Is resolving this in near sight?
    I believe this turned out to be a very minor issue and has been resolved for the next beta. Basically, you can change it as long as you don’t change it to "default". As far as I’m aware all named manager themes work.

    Quote from: JeremyL at Sep 16, 2006, 04:57 PM

    1. Ajax Search links lead to dynamic urls "index.php?id=9" even though I have static sef urls turned on.
    True. Thanks for pointing that out. That does need fixing for the full release.

    Quote from: JeremyL at Sep 16, 2006, 04:57 PM

    2. (related to above) Dynamic urls are usable creating duplicate content issues with search engines.
    Your 301 idea is good, however I think that should be toggleable. I’ve used ?id=7 for testing purposes previously when porting parts of a site to MODx (if billy.html exists, the htaccess shows that; once I’m happy with ?id=7, I can delete the old billy.html file). So I would consider that it is not a bug/problem but rather a wishlist extra that shouldn’t hold up 0.9.5.

    Quote from: JeremyL at Sep 16, 2006, 04:57 PM

    3. ... Also noticed www.domain.com/quickstart.html and www.domain.com/quickstart are the same thing via the browser no matter what is sellected in settings.
    The extension has been optional for some time - this facility enables many things such as having an alias called styles.css or feed.xml, which lets you reference an editable file in headers etc without the extension. This facility should not be removed without adding the ability to over-ride the extension.

    And with directories, I guess the problem is that one might have the page features.html one day, and later add child pages, which with certain settings become features/ajax.html. Yes, some users will edit that to "features/", but I’m not sure that is distinguishable from "features", and as that *is* desireable (due to the above issue)..

    Hmmn. Interesting issue. As I say, not a big 0.9.5 showstopper but worth resolving, especially now we have better facilities for handling redirects. Personally, I’d like to see a full facility for handling redirects - it would be great to have MODx default to being very strict, but pass everything else through to a module. That module could then be configured to handle redirects and additional aliases - eg page.htm to page.html. I have one site that I’d love to redirect page.asp to page.html, and another where I’d love to redirect product_info.php?products_id=1084 to products/combi-drill.html. Equally, it should be possible to set style.css to use the data from a MODx page without telling the browser about redirection.

    Thanks all for comments and feedback though. I can say that we’re working on the new default content - we’ll certainly check out the blog post issue etc, but a few things will be resolved just from the switching to newer snippets.
      No, I don't know what OpenGeek's saying half the time either.
      MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
      Forum: Where to post threads about add-ons | Forum Rules
      Like MODx? donate (and/or share your resources)
      Like me? See my Amazon wishlist
      MODx "Most Promising CMS" - so appropriate!
      • 28042 ☆ A M B ☆
      • 24,524 Posts
      I just updated my site, and ran into something rather surprising. Ever since TVs first got added to the core, I’ve used them exactly the same as I do the document content; that is, I often just put plain HTML code in them. With the upgrade, however, this HTML code is being displayed exactly as entered, tags and all.

      On investigating, I found that there are more input types than there were, and I needed to change from "textarea" to "raw texarea".

      I thought it would be a good thing to mention so it doesn’t come as too much of a shock to others.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 16511
        • 16 Posts
        I’m either missing something obvious, or this is a serious bug.

        Create a template with a QuickEdit TV in it (e.g. [*#pageimage*]) with input type Image and widget type Image. Create a page based on that template, but leave the value for the Image TV empty.

        View the page and click the QuickEdit button for the Image TV. Select an image from the Resources Browser, then click OK. This error message appears:

        « MODx Parse Error »
        MODx encountered the following error while attempting to parse the requested resource:
        « Execution of a query to the database failed - Unknown column ’editedon’ in ’field list’ »
        SQL: UPDATE modx_site_tmplvar_contentvalues SET editedon=’1158495453’,editedby=’1’ WHERE id = ’2’;
        [Copy SQL to ClipBoard]

        Parser timing
        MySQL: 0.0030 s (5 Requests)
        PHP: 1158495453.2988 s
        Total: 1158495453.3018 s
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          Looking at the database, that table has four fields: id, tmplvarid, contentid, and value. That’s a bug; an image type TV isn’t getting the proper setting to flag it as a TV as opposed to regular document content.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 16511
            • 16 Posts
            Good to know. I’m able to edit the TV’s value using the Manager -- the problem only seems to happen when editing it with Quick Edit. Nevertheless, a fix would be appreciated.
              • 25663 MODX Staff
              • 12,272 Posts
              Quote from: sottwell at Sep 17, 2006, 01:33 AM

              I just updated my site, and ran into something rather surprising. Ever since TVs first got added to the core, I’ve used them exactly the same as I do the document content; that is, I often just put plain HTML code in them. With the upgrade, however, this HTML code is being displayed exactly as entered, tags and all.

              On investigating, I found that there are more input types than there were, and I needed to change from "textarea" to "raw texarea".

              I thought it would be a good thing to mention so it doesn’t come as too much of a shock to others.

              Sounds like we need to switch the behavior of raw text areas and give the new behavior the name of "escaped text area", or something like that.
                Ryan Thrash, MODX Co-Founder
                Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: lovingmodx at Sep 16, 2006, 08:41 PM

                I tried the fake virtual directory to see if it returns 404 error now. It do, but the 404 page in fake directory is unable to load the sytlesheet from the correct path, so the page cannot be render by the stylesheet. I use firefox webdeveloper toolbar to ’view css’ and confirm that the browser do try to load the stylesheet from the fake-dir. Same for IE.

                mysite.com/fake-dir/assets/templates/modxhost/layout.css (and all other css script)

                * fake directory means not existing directory/ghost directory.
                You need a base href tag set to the site_url in your template before any CSS paths; assuming you have authored your content in a portable way (i.e. all paths relative to the root of the MODx site), this should work for all your templates. Otherwise, create a custom one for your error_page that does include this.
                  • 22303 MODX Staff
                  • 10,725 Posts
                  Quote from: sottwell at Sep 17, 2006, 01:33 AM

                  I just updated my site, and ran into something rather surprising. Ever since TVs first got added to the core, I’ve used them exactly the same as I do the document content; that is, I often just put plain HTML code in them. With the upgrade, however, this HTML code is being displayed exactly as entered, tags and all.

                  On investigating, I found that there are more input types than there were, and I needed to change from "textarea" to "raw texarea".

                  I thought it would be a good thing to mention so it doesn’t come as too much of a shock to others.
                  I’m confused, the behavior on this was just reverted not to use the htmlentities call anymore?? This should not still be an issue, as both the raw and regular forms are now doing the exactl same thing again.
                    • 28042 ☆ A M B ☆
                    • 24,524 Posts
                    So what’s the difference between "textarea" and "raw textarea" then?

                    This was taken from garryn’s branch anyway, I was interested in checking out some stuff he did, so it may not behave in the same way in the main "trunk".
                      Studying MODX in the desert - http://sottwell.com
                      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                      Join the Slack Community - http://modx.org
                      • 22303 MODX Staff
                      • 10,725 Posts
                      Quote from: sottwell at Sep 17, 2006, 11:59 AM

                      So what’s the difference between "textarea" and "raw textarea" then?
                      There isn’t one on the rendering side for now. Discussion of this issue started here.

                      This discussion is closed to further replies. Keep calm and carry on.