Support/Comments for TinymceWrapper

I didn't duplicate it, so I believe it has been overwritten. With your latest changes I think I've had no reason to change it this time. I've set the Window10 theme in the pset, etc.

I've reinstalled, and it just won't use my property set. I even created a fresh one, think perhaps the set was invalidated by changes or new options. The name of the set reaches all the way down to the jQuery call in the browser resource, but after that it's just running the default property set.

Hang on. Where should the elfinderConnector snippet factor into all this? It looks like it's using "[[++assets_url]]components/tinymcewrapper/browserConnectors/elfinder.php" instead at the moment, which might explain why my property set is being ignored, but not why the default property set isn't.

I doubt this is related, but looking at the source for the elfinderConnector snippet I notice that on line 45 you have:



It seems to me that that should end with "$sP" with a cap 'P'. Variable names are case-sensitive, no? So far I've had no need of those chunks, and therefore no need to duplicate them or add custom suffixes, so even if that is a problem it likely isn't affecting anything I'm interested in.

Hello David,

I am currently unable to reproduce your present issue.

1. Are any other custom settings of TinymceWrapper being ignored?
2. Is it only the pset of elFinder that is being ignored?
3. Are all your properties of the elFinder pset being ignored?

YES ... the elfinderConnector snippet is called by
[[++assets_url]]components/tinymcewrapper/browserConnectors/elfinder.php

elFinder.html must post to elfinder.php

Something is rotten in the State of your TW installation - 'tis very peculiar
I need to see with my own eyes to verify the issue.

Thanks for catching the typo.
In your case it is a non issue, and so for most people.
The case error will simply prevent people from using custom chunks
Will be corrected in next release to be all uniform either to $sP or $sp

I've spent two evenings trying figuring out why Articles extra didn't worked, thought it's Articles' bug, but after clean modx reinstall and few tests with installing-deinstalling extras i just found that TinymceWrapper (with default state right after install) somehow conflicts with modx when Articles extras installed and makes any create resource (tried regulars docs and articles) page not working (shows blank page).

Quote from: donshakespeare at Mar 17, 2016, 11:07 PM

1. Are any other custom settings of TinymceWrapper being ignored?

It seems not. I've successfully renamed the top nav button to simply say "File Manager" so it's not so odd for users. I believe I'm using a chunk suffix but haven't actually paid enough attention to the editor toolbar to know at this stage.
Quote from: donshakespeare at Mar 17, 2016, 11:07 PM

1. Is it only the pset of elFinder that is being ignored?

What else is there that I could check? I've set the theme using the URL parameter, so that works. I've also been able to remove the rather pointless and confusing "Places" item at the top of the folder tree by editing the resource (would you consider removing that from your next release?).
Quote from: donshakespeare at Mar 17, 2016, 11:07 PM

1. Are all your properties of the elFinder pset being ignored?

I believe so. I'm unable to configure any of the locations, and the entire remains locked.

I've just reinstalled from scratch, making sure all files were properly deleted from the web server, created entirely new property sets and I'm still having the same issue. I wonder if there's some compatibility issue, but my installation is quite simple. The only concern I have left is that I already had codemirror running, so I can only hope it doesn't cause issues with Tiny now that it's included, but that still shouldn't have anything to do with elfinder.

It's starting to look like I need to look into the component source to track down why the property set isn't being successfully accessed. I presume something is failing along the way and it's reverting to the default properties. I'll either end up having to edit the default properties, which'll suck, or just give up on elfinder altogether.

To be honest, I still don't understand why you don't see the point of media sources. If I end up with the native modx browser again at least I can use those. It's important (to me, and almost anyone I have managing a site after I've built it) that certain assets (images/documents) that are uploaded are correctly organised. All too often I have users making a mess of site files, leaving them flapping around in the root because they're so alarmingly ignorant. Now media sources comes along and makes all kinds of sense - I'm at a loss as to why you wouldn't see the benefit of being able to ensure that blog thumbnails go into one specific area, while PDF downloads from other site pages are stored somewhere else.

I suppose the simple response to that might be to say that you don't really care where the stuff goes. WordPress certainly doesn't, so why not just have everything in one folder and just set that up as a single location in elfinder. But then you have one monolithic folder of crap users have to sort through to find individual items. It makes all kinds of sense to organise, and media sources are the best aid for that. I'd love to see them integrated into elfinder as a means to automatically configure locations, or some such. Any given TV "Browse" button will only need to set up a single location for the user to be concerned with. [ed. note: davidsmith last edited this post 8 years, 1 month ago.]

Ok I've continued my investigation, following the process of spinning up elfinder to establish where it drops the pset directive. It turns out elfinder.php isn't getting $_GET['pset'].

The elfinder resource HTML/js uses the following:



[EDIT:] I presume the intention is that the 'customData' values are encoded along the way by the elfinder .js library into url parameters for the 'url', but that doesn't appear to be happening. Given that elfinder.php needs nothing more than the optional 'pset' parameter, unless there's something specifically wrong that needs fixing, couldn't the 'pset' parameter just be appended to the 'url' in the code above?

[EDIT:]The more pressing questions are "why does yours work and mine doesn't?" and "when do those 'customData' become url parameters for elfinder.php, and why don't mine?"

[EDIT:] I'm thinking it's actually just the "customData" object that isn't behaving as expected. "rememberLastDir" seems to work, I think, but the values for "pset" and "unlocked" etc. within the "customData" object aren't being translated to url parameters for elfinder.php.

[EDIT:] I've updated my elfinder resource jQuery code to include the '?pset=' parameter, using the TinymceWrapperGetUrlParam snippet, and that seems to work.

[ed. note: davidsmith last edited this post 8 years, 1 month ago.]

RE: modxor

i just found that TinymceWrapper (with default state right after install) somehow conflicts with modx when Articles extras installed and makes any create resource (tried regulars docs and articles) page not working (shows blank page).

Sorry for your pains. Looks like something went terribly wrong in the atmosphere. Let me check ...
Okay here we go:
In your TinymceWrapper Plugin Properties (preferably your own pset), turn off TinyJSONGallery

In addition to the list of known incompatibilities:
Image +
Gallery

If enableImageGallery is turned on ...creating new resources of any kind (Articles included) bounces a blank dead error page

Thanks for reporting, will be fixed in an ASAP patch.
Cheers [ed. note: donshakespeare last edited this post 8 years, 1 month ago.]

RE: Dave Smith

I've also been able to remove the rather pointless and confusing "Places" item at the top of the folder tree by editing the resource (would you consider removing that from your next release?).

Is it pointless in itself or pointless to you? Do you know the function of elFinder Places? It is a bookmark of most commonly used folders. A user can drag and drop any and all most-frequented folders into Places. Folder locations are then shortcutted via JS cookie. You may use your own elFinder resource, as customized as you wish, because the elFinder html in MODX is pretty standard such as can be found on the official elFinder github.

To be honest, I still don't understand why you don't see the point of media sources. If I end up with the native modx browser again at least I can use those. It's important (to me, and almost anyone I have ...

I suppose the simple response to that might be to say that you don't really care where the stuff goes...

I don't know that I don't see the point of Media Sources. And I don't know that I don't care where stuff goes - these are assumptions you'd have to pick up with your town magician.
In fact I do understand them thoroughly. They are only useless to me, myself and I personally - because I have private alternatives and powerful solutions. Not every driver is fascinated about everything in his car.

Besides I have elFinder MODX Media Sources on the road map, in case you missed it ...scroll down on this link
https://forums.modx.com/thread/97694/support-comments-for-tinymcewrapper?page=19#dis-post-538232

I've updated my elfinder resource jQuery code to include the '?pset=' parameter, using the TinymceWrapperGetUrlParam snippet, and that seems to work.

Yes, the old hack solution is a valid one. You may use it at this time if all else fails for you.

Until I or another person reproduces this issue, I am going to be drinking a smoothie.

Apologies if I come across a little judgemental. It's not intentional. I'm glad you're considering Media Sources. Having up to 5 hard-coded areas in a browser, with no way to control where certain assets are funnelled when users upload certainly seems "less good" to me, but if you could achieve both then that would be outstanding.

As for places, I actually had no idea it could be used that way, and so I totally missed the point. Perhaps I could be forgiven for not realising its purpose given that it's not entirely obvious, though others may disagree. But given how simple web file management is (I use Media Sources to make it simpler still, for users, and if you don't then I can only imagine you're either using something else we haven't discussed, or you feel it's simple enough already) it doesn't seem likely that anyone is actually going to want that particular feature. But as you've repeatedly pointed out to me, just because I don't appreciate a feature doesn't mean others won't, and visa versa.

Getting back to the problem at hand; are you able to confirm that the items under "customData" should be being delivered via $_GET[] to elfinder.php? Unless that's true, giving me something else to investigate, I can't quite imagine how it could possible work. In addition, I'm wondering if there's a drawback to my hack. If the 'pset' parameter isn't successfully delivered via 'customData' will that information then be unavailable at other times when it's expected?

It has also occurred to me that the 'unlocked' flag, at least, is included in both the TinymceWrapper property set URL string, as well as the elfinderConnector property set, and so it seems redundant in the 'customData' set in the elfinder resource jQuery call.