We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 42562
    • 1,145 Posts
    So from:
    https://forums.modx.com/thread/97694/support-comments-for-tinymcewrapper?page=45#dis-post-553723
    I had this note in there (which, as it appears, is very serious!!!)
    content_css: "css/style.css", // must exist/be accurate/contain said classes/ and, preferably local CSS file [


    The reason is, I quote:
    It can't import cross domain on some browsers. So the URL needs to be local.
    And https and http, and www and non-www means yuugge non-same difference (apparently!)

    If your MODX config is forced to use https and no www you access your manager from:

    www.example.com/manager
    content_css : "/css/styles.user2.css", // translates to https://example.com/css/styles.user2.css
    content_css : "https://www.example.com/css/styles.user2.css",
    content_css : "[[++base_url]]css/styles.user2.css",  // translates to /en/css/styles.user2.css (forced to https)
    

    All the above will fail.

    use this instead
    content_css : "http://www.example.com/css/styles.user2.css",


    Basically, if your MODX spits out https://example.com/ for [[++site_url]]
    then make sure your htaccess prevents any kind of access to www.example, http:// ... etc
    #Force non-www:
    RewriteEngine on
    RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
    RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]


    This www and non-www used to affect SEO rating, as per duplication fears or something like that.
    And yes, as BobRay said, session is not carried over, and you will run into this same problem on another more ruinous level in future.

    Cure that htaccess issue right away!
    Your site should not be allowed http.example or http://www.example or www.example
      TinymceWrapper: Complete back/frontend content solution.
      Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
      5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
      • 42562
      • 1,145 Posts
      But if for some strange reason you need your system the way it is
      Here is a dynamic JS hack

      In your content chunk for example
      var content_css_http, content_css_www;
      if (location.protocol == 'https:') {
        content_css_http = "https://";
      }
      else{
        content_css_http = "http://";
      }
      if(window.location.host.indexOf("www") === 0){
        content_css_www = "www.";
      }
      else{
        content_css_www = "";
      }
      content_css_url = content_css_http + content_css_www + "example.com/css/styles.user2.css";
      tinymce.init({
        selector: "#ta",
        [[+commonTinyMCECode]]
        ....
      });


      And in your common code chunk
      content_css : content_css_url,


      And however your site is accessed, the menu should work as expectedly.
      This was tested on your site.
      Cheers. [ed. note: donshakespeare last edited this post 6 years, 6 months ago.]
        TinymceWrapper: Complete back/frontend content solution.
        Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
        5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
        • 24374
        • 322 Posts
        We've really gotten sidetracked into a discussion of HTTPS setup, and none of these responses explain why the editor shows up fine in two contexts but not in the other contexts.

        BUT, I just logged in this morning, and the styles are showing up correctly for all contexts now. I see you added some code in the "content" setup chunk to alter the URL for the style sheet dynamically, so maybe that's what made this work, although I still don't understand why that's necessary. And, why not just use window.location.hostname instead of the check for www and non-www? (content_css_url = content_css_http + window.location.hostname + "/css/styles.user2.css";) I entered that, and it works fine for me.

        HOWEVER, htaccess is not forcing www or non-www and isn't forcing SSL either, so the relative address for the style sheet should already load at whatever domain name the manager is loaded at, right? I've also got code in there to allow cross-domain access to CSS files.

        This ONLY works when logging in at the non-secure address, though. If I log in at https, then TinyMCE only loads for the first two contexts. The additional contexts load a site at a different domain, and that domain doesn't have an SSL certificate yet. I don't know why that would interfere with the manager loading TinyMCE for these contexts when logged into the secure site, but I'll see if that's fixed once the certificate is installed. It doesn't matter if there is nothing entered in the content field for a resource, there is just a blank space where TinyMCE should be, and no error messages are displayed or recorded anywhere. Shouldn't I be able to edit any resource in the manager, regardless of what domain name it loads at in the front end?
          • 42562
          • 1,145 Posts
          Please re-read this
          https://forums.modx.com/thread/97694/support-comments-for-tinymcewrapper?page=46#dis-post-553785

          I don't know how else to rephrase it. [ed. note: donshakespeare last edited this post 6 years, 6 months ago.]
            TinymceWrapper: Complete back/frontend content solution.
            Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
            5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
            • 24374
            • 322 Posts
            Installed the SSL certificate for the second domain, and now TinyMCE is working for all contexts. So, the issue does NOT have anything to do with SSL versus non-SSL setup specifically, as I suspected. TinyMCE must be using the domain from the context settings for some things, most likely the content css file and maybe some other stuff. My question is, why? I would have expected that the css path entered into the TinyMCE settings would load that file relative to the domain you're logged into for the manager itself.

            This also means that the change I made to the JS you added to the settings is the only thing that will make this work. Your line was:

            content_css_url = content_css_http + content_css_www + "example.com/css/styles.user2.css";


            which has the domain name hard-coded into it. If some contexts use a different domain, this will fail, so you HAVE to do this:

            content_css_url = content_css_http + window.location.hostname + "/css/styles.user2.css";



              • 42562
              • 1,145 Posts
              Let me try to explain step by step. Please follow closely.


              1. TinyMCE uses the URL you supply it and nothing else, no other magic!
              2. In your case the URL was completed by MODX. the part you did not hardcode, i.e.everything before the first forward slash (/css/etc/etc)
              3. URLs that have www and those that don't are not equal (main issue for you!!!!!!!!!!!!)
              4. URLs that have http and those that have https are not equal (will bite you soon enough, unless you have it fixed already)
              5. If you do not use htaccess to force only one single kind of access to your site, you will run into future problems of URL MISMATCH, that JS hack I gave you will not save you
              6. That JS hack works/needed because you have a problem with your MODX/site setup:
              7. If there is a URL mismatch, [content_css] will fail (because it does not work cross-domain)

              ...My question is, why? I would have expected that the css path entered into the TinyMCE settings would load that file relative to the domain you're logged into for the manager itself.
              That is what it does! ...

              BUT

              While your setup is very close to being perfect:
              example.com/css/styles.user2.css //VALID
              example.com/en/css/styles.user2.css //VALID
              example.com/sp/css/styles.user2.css //VALID
              
              example-neighbourhood.com/css/styles.user2.css //VALID
              example-neighbourhood.com/ps/css/styles.user2.css //VALID
              etc etc

              ...

              8. Whether you access MODX via www or no www .... or ....http or https
              the default official internal URLs remain the same as that in the MODX System Setting/Context Settings

              a. www.example.com (internal official url is still: https://example.com)
              b. example.com (internal official url is still: https://example.com)
              c. https://example.com (internal official url is still: https://example.com)
              d. http://example.com (internal official url is still: https://example.com)


              * You accessed your site via:
              https://www.example-neighbourhood.com,

              * but TinyMCE looked for the CSS file in:
              MODX' url https://example-neighbourhood.com
              * * * TinyMCE will NOT get the file (although it exists)

              This also means that the change I made to the JS you added to the settings is the only thing that will make this work.
              * The JS hack just looks up plainly at the Manager browser URL (not any context or stuff)
              and rebuilds a workable URL
              So, yours works because it will always be the exact same thing as mine.

              *** This JS hack is client-side, and overly specific. You need htaccess to lock out [www] access to your site, so that access URL can match your MODX internal URL

              I am considering this sufficiently addressed.

              Cheers.
              [ed. note: donshakespeare last edited this post 6 years, 6 months ago.]
                TinymceWrapper: Complete back/frontend content solution.
                Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
                5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
                • 50722
                • 35 Posts
                Hello,

                I've got a fresh TinymceWrapper install running and have gone through the steps to create custom property sets to keep the original intact. I'm having a few issues so will start with elFinder - I have this problem in both Admin and Editor accounts to varying degrees.

                Originally I had vanilla TinyMCE installed and then added TinymceWrapper and set that to default. I had no problem inserting/uploading images with TinyMCE but I do now with TinymceWrapper. First thing I did was check the directory setting on the server and all image dirs are set to 0755, so I assume that discounts any write-access prob on the server.

                Admin account - when I try to upload images in elFinder I get the following error message (otherwise all seems fine):


                Editor account - if I try to insert an image in a Resource, when elFinder opens I get the following message and I can't go any further:


                As errors happen in both accounts I assume it points to a TinymceWrapper config thing as opposed to an account permissions thing. But I did say I assume!

                Any help would be much appreciated.

                Thanks in advance. [ed. note: powellian last edited this post 6 years, 6 months ago.]
                  • 50722
                  • 35 Posts
                  Imagine this will help:
                  MODX Revolution: 2.5.7-pl (traditional)
                  PHP Version: 5.6.30
                  MySQL Client API version: mysqlnd 5.0.11-dev (from phpinfo file)
                  Database client version: libmysql - 5.1.73 (from phpMyAdmin)
                  Server version: 5.6.35 - MySQL Community Server (GPL) (from phpMyAdmin)
                  Protocol version: 10
                    • 42562
                    • 1,145 Posts
                    RE: powellian

                    I had no problem inserting/uploading images with TinyMCE but I do now with TinymceWrapper. First thing I did was check the directory setting on the server and all image dirs are set to 0755, so I assume that discounts any write-access prob on the server.

                    The issue you are having is due to an improperly configured elFinder. From the picture in your post above, I assume it is the elFinder File Browser giving you the error, and not MODX per se or the RTE.

                    Since I am spending most of my non-available free time finishing the new release of everything, I suggest you switch from elFinder to the MODX native File Browser - uploading there, gives no issues, I warrant.

                    Cheers.
                      TinymceWrapper: Complete back/frontend content solution.
                      Harden your MODX site by passwording your three main folders: core, manager, connectors and renaming your assets (thank me later!)
                      5 ways to sniff / hack your own sites; even with renamed/hidden folders, burst them all up, to see how secure you are not.
                      • 47717
                      • 144 Posts
                      Just wondering if the plugin works now "out of the box" without troubles ?
                      I used it months ago, and had to delete it due to many minor inconveniences.
                      thanks