Yes, this information was quite helpful, although I still had to do some debugging since the page referenced maybe used a version of FCKeditor different from what was in the XOOPSeditor 1.10 package. Probably the best information was that there is a test page available for this to make it easier to test and troubleshoot -- one for browsing and one for uploading. However, once you fix one, you can then just transfer the same line to the other location. I started with file browsing and then fixed the one with uploading. They all fall into the function fckeditor_root_path (which is a misnomer since it's really xoopseditor_root_path that it's giving you to include the xoopseditor.inc.php file. Whatever. I got it to work.

If you want to get FCKeditor running on the XOOPS 2.0.x branch, then try my post on implementing FCKeditor on 2.0.x. Hope it helps.

Like many of you who posted on this site, you've struggled with implementing FCKeditor on your XOOPS 2.0.x installation. Here are the instructions and information to get it running for you. It includes the ability to upload images and other files allowed in FCKeditor sitewide as well as for specific modules if you want to have separate locations for separate modules. [Note: This uses the XOOPSeditor v1.10 download. I used this on 2.0.16, but I expect that it will work for most of the 2.0.x versions. Also, since I'm now on PHP5, there may still be some other code in there that doesn't work on PHP4, but I don't have PHP4 servers available for testing anymore, so your mileage may vary. But the one fix I proffer here is a PHP4 & 5 solution.]

If you have questions, post to this topic and I'll answer and clarify. I've also posted instructions formatted in HTML on my website. That may be more readable than what I can accomplish here.

If you want, instead of doing this editing, you may want to just download my update to FCKeditor.

HOW IT WORKS (DEVELOPER VIEWPOINT)
----------------------------------
In essense, this implementation will build a variable $uploadPath which is tacked onto the XOOPS_UPLOAD_URL which is the XOOPS_ROOT."/uploads" directory. So ALL of your files will be there (unless you do some additional hacking -- not recommended).

This implementation of FCKeditor will look for configuration files in the module directory and use those settings. If it doesn't find the files there, then it uses a default specification (XOOPS_ROOT/uploads/fckeditor unless you change per instructions below).

Under this FCKeditor upload directory, depending upon your usage, it will create the following subdirectories for uploaded content: Image, File, Flash, and Media (yes, case sensitive). You do NOT have to create these yourself, although you may run into permission issues that you may have to fix (more info below)

IMPLEMENTING FCKeditor
----------------------
In short, here are the steps to get FCKeditor (included in XOOPSEditor v1.10) working for your modules (in 2.0.x, where I was using 2.0.16):
- Download XOOPSeditor 1.10 and install per instructions - use the readme.txt file.
- At this point, FCKeditor is in this folder: XOOPSROOT/class/xoopseditor/FCKeditor (don't change this folder name due to some hard-coding)
- Modify any calls from your modules that aren't using this path to point to this location (I realize some specify fckeditor instead of FCKeditor, but due to hardcodings, you'll not want to change that).
At this point, the editor should generally work (except maybe for uploads).

ENABLING FCKeditor UPLOADS
--------------------------
To have uploads work (for images), you will have to edit these files (from FCKeditor folder) due to some error in coding (I couldn't figure out what was trying to be done but I got it to work right):
- /editor/filemanager/browser/default/connectors/php/config.php
- /editor/filemanager/upload/php/config.php
What you want to do is modify two lines:
$fckeditor_root_path = substr($current_path, 0, stripos($current_path, basename(dirname(dirname(__FILE__)))."/editor"));
to be:
$fckeditor_root_path = dirname(substr($current_path, 0, strrpos($current_path, "/editor")));
and (in case you want your upload path to use subdirectories and not strip out the slashes)
if(!defined("XOOPS_FCK_FOLDER") || !$uploadPath = preg_replace("/[^a-z0-9_\-]/i", "", XOOPS_FCK_FOLDER) )
to be:
if(!defined("XOOPS_FCK_FOLDER") || !$uploadPath = preg_replace("/[^a-z0-9_\-\/]/i", "", XOOPS_FCK_FOLDER) )
- if you want, edit the $uploadPath variable (about line 50) in both config.php files as well for the default path (default is fckeditor).

UPLOAD FILE PERMISSIONS
- files are created with 777 permissions unless you change line 206 of editor/filemanager/browser/default/connectors/php/commands.php and line 109 of editor/upload/upload.php to the permissions you want
- folders are created with 777 permissions unless you change line 73 of editor/filemanager/browser/default/connectors/php/io.php to the permissions you want

Notes:
I disabled the Upload tab on the main Image/Flash insert window because these files uploaded into the uploadPath directory and thus weren't browsable later using the Browse Server button on the Image Info, Flash Info or Link tabs. I did this in the editor/filemanager/upload/php/config.php file, line 47, setting $Config['Enabled'] = false;. I was still able to upload using the Browse Server button pop-up. Until we can see the files with the browser, it doesn't make sense to use this upload tab.

I also wanted to use server relative URLs because I make a basic server setup that I replicate to many sites, so then I had to make changes again....
I changed line 55 of editor/filemanager/browser/default/connectors/php/config.php and line 51 of editor\filemanager\upload\php\config.php from:
$Config['UserFilesPath'] = XOOPS_UPLOAD_URL."/".$uploadPath."/" ;
to:
$Config['UserFilesPath'] = str_replace(XOOPS_URL,"",XOOPS_UPLOAD_URL)."/".$uploadPath."/" ;
This just removes the portion with your server name. Relative URLs rule for content!

MODULE SPECIFIC UPLOAD DIRECTORIES
Finally, if you want to enable module specific versions of this, then for each module that you want to have different from the global settings, here is what you do:
- copy the files from the FCKeditor/modules folder to the directory of the module in which you want an upload area named by module.
- edit MODULE/fckeditor.upload.php and ENABLE uploads (if you want), by disabling the FCKUPLOAD_DISABLED variable: define("FCKUPLOAD_DISABLED", 0);
- Note: If you are troubleshooting and make any changes, you will want to clear a cached file in the cache directory for each module, named XOOPS_ROOT/cache/fckeditor.MODULE_NAME.js to have the changes take effect.

Clear as mud? Hope so. But if you still are having problems, then you can use the two test files included to help troubleshoot your installation just like I did:
http://yoursite.com/class/xoopseditor/FCKeditor/editor/filemanager/browser/default/connectors/test.html and
http://yoursite.com/class/xoopseditor/FCKeditor/editor/filemanager/upload/test.html

Things I would like to see:
- Toolbars. I'd like to offer Users just the basic toolbar and then offer other groups (Admins and privileged content contributors) the ability to use the full toolbar. I see this in the implementation for Drupal, so I'm sure it can be done here. That's left for another day for me. I assume that even though the toolbar isn't there, I can still upload just about any HTML, though, so I'm not sure if it buys any security for the site.
- Options moved to config file. Many of these changes can likely be moved to the configuration file(s). This includes permissions, paths, etc. I expect that is where one would likely want to add the module info, too.

Many thanks to the following posts for helping me to get this going:
XOOPS: Post 1 | Post 2 | Post 3;
XOOPSInfo Post
which also pointed to this XOOPSforge thread which also pointed me to the test URLs. From all of these pointers, I was able to figure it out. Hope it helps you!

LOL. Nope, not asking for much, eh?

Probably the best information for developing a module is on the XOOPS Dev site in their Development Wiki. Try section 2. Module Development. I've contributed some there as well as others.

Also, there are a couple of module generators out there that will build the very basic framework of a module. Then you flush it out. Building that framework can take a little time. Plus, if you find a solid, mature module and take it apart, or at least reference it during a build, then you'll have a solid idea of what is going on.

Hope that helps.

I, too, am running into the same issue. I am running XoopsFrameworks 1.10 and XoopsEditor 1.10 on XOOPS 2.0.16 with SmartSection (you have to edit the smartsection functions.php file to point to FCKed correctly). The editor generally works fine, except for dealing with images.

Per this post, I created the uploads/fckeditor/ directories as specified and checked the file permissions, I made sure the uploader was enabled in the configuration file. I also tried manually loading some image files via FTP into those directories. I see none of the images in the FCKeditor image manager, and can't upload a file or create a directory, either, with FCKeditor. I'm afraid that maybe I've not got something configured quite right, either, but for the life of me I can't figure it out, yet. Still working on it because I too want this to work.

I also tried making these directories in the smartsection module. I also tried copying the module files into the smartsection directory.

I wouldn't expect this to be that hard. I'm usually pretty good at following directions (such as those posted on the XOOPSEditor site for FCKeditor). I'm now to the point of frustration.

Mark

Well, okay. I've reconsidered, and I'm back. LOL. At least I'm back in.

My preference is to stick with XOOPS at this point. I've got a lot of time and effort invested in it. As you know, any CMS, to do it right, you have to invest time in it. You can start easily with any of them, but to make it yours, you have to crawl under the hood.

I've crawled under almost every nook and cranny of XOOPS. And in the spirit of community, worked to contribute back where I can.

Owning my own ISP, being a community organizer, and also a consultant and developer, I know what it's like to have many irons in the fire and manage them all. I look forward to the new XOOPS site, and the other things we all are working on. Together, we can create change, and make a difference.

I hope that I don't get banned again, but at least I have an e-mail of someone on the team now that can assist. I felt lost using lynx since I couldn't PM people I knew could help. At least I was able to post in these forums.

So, I'm still around, and will remain so, and re-engaging again in my contributive manner. I just hope that Protector won't ban me again.

Thanks,

Mark

I must say goodbye, I'm afraid. I love XOOPS. I contributed to the XOOPS dev manual. I have built several sites with XOOPS and continue to maintain them. I have been building a super site for my hosting clients (I do webhosting at http://www.noise.org). But, alas, it appears I must leave.

Probably the biggest issue right now is the fact that I can't seem to stay connected to the XOOPS.org website. I never had this problem before, but my IP has been banned more than once just from using the site - posting, researching, etc. If I can't reach the site, then I can't use the software or contribute to the community.

I do have a few more things to contribute. I have a port of SmartProfile that works on PHP4. It's also ported to the /modules/profile directory (ala XOOPS 2.2.x) so that you can use xosCommerce (works great btw).

I've been frustrated with integrating the WYSIWYG editors, especially FCKeditor and image management which I can't get to work. I tried to post about it, but I can't get to the site from this IP address (and I can't change IP addresses -- I've tried). I was only down for 1/2 a day last time. This time I've been down more than 24 hours. And I posted about it in the forums, but no response.

I figure I triggered protector module. See, when I do research, I'll do a search, and then I'll open several new tabs of results in Firefox at once. That is likely what happened, but now I can't get back in again.

I've been working with Drupal lately, too. It has some misgivings, but it has some great stuff too. I need to make a long-term investment in an architecture for the site that I'm building to offer to my clients. I'm in the middle of it, in critical path, and on a deadline to get it done. But alas, I can't.

I posted recently about what I like about XOOPS and what is missing. The forward direction of XOOPS was announced 18 months ago or more. We're still missing a number of critical aspects that will keep this going. I've been trying to contribute and was about to release some contributions and updates to debaser, xcGallery, SmartProfile (my PHP4/profile port). But, I was trying to get all my stuff ready including some of the bugs I was having.

So, alas, with much sadness, I've decided I must move on. XOOPS is better on so many levels, especially from a programming standpoint and a caching standpoint (lightweight on the servers).

Adios, adieu, tschuss, goodbye. And best of luck.

I did try clearing my browser cache, rebooting, etc., but that didn't do it. I didn't clear my cookies, though. BTW, I use a broadband connection (cable) with a firewall and router on the inside.

However, I was able to login to the site using lynx (a text-based web browser available on most linux systems). So, I decided that it had to be IP based. I looked on my own sites (I use Protector, too, of course) at the settings to see what I might have triggered, but I'm still not sure.

In the end, a few hours later, I was able to get back onto the site.

I hope this helps others. Peace,

Mark

Doh! I had to change the php.ini settings to allow larger file uploads. After that, I was able to get it to work again. I had rebuilt PHP on the server and upgraded it to 5.2 and that's when the filesize went back down below our normal settings. The pertinent settings are:

post_max_size
upload_max_filesize

You can check your settings by making and running a php file with only phpinfo(); as the only instruction. It will also tell you where the ini file is (assuming you have access). If you don't, you will need to contact your hosting provider. Some setups allow you to override some settings on a local web, but they can help you on that.

Hope that helps.

Mark

Well, I'm back in again. Not sure what happened, eggzactly, but am happy to be back. Thanks. --M

That is a good suggestion, of course, but, no I had tried that. Their DHCP server apparently holds onto the MAC address or something. I even tried releasing it first, then cycling the power on both the cable modem and the internal router. Same IP/Gateway, unfortunately. I also tried PM'ing, but lynx won't do that. The proxy servers I found won't hold enough information to keep me logged in to post, so lynx it is. Thank goodness for notifications via e-mail. And thanks for your assistance and help. I'm in the midst of a project and it's certainly causing problems for me. I have posted a few posts today and yesterday, much aflurry compared to other days. --Mark