22
What do you get if you save the following file:
and save it as:
/var/www/vhosts/wodenses.org.au/httpdocs/helloworld.php
Then view it by going tohttp://wodenses.org.au/helloworld.php to see what it looks like.
Do you get the same error??
<!-- This goes at the top of your html file -->
<?php
include_once '../mainfile.php'; // Load basic XOOPS environment (required).
include_once XOOPS_ROOT_PATH.'/header.php'; // Load page header (required).
?>
<h1>Hello, world!</h1>
<p>This page should show up and be wrapped inside your XOOPS theme and such to look like any standard XOOPS page.</p>
<!-- This goes at the bottom of your html file -->
<?php
include XOOPS_ROOT_PATH . '/footer.php'; // Load page foot (required).
?>
and save it as:
/var/www/vhosts/wodenses.org.au/httpdocs/helloworld.php
Then view it by going tohttp://wodenses.org.au/helloworld.php to see what it looks like.
Do you get the same error??
23
I'm probably not understanding you correctly, so I apologize if this post wastes your time.
Yes, there is a session created by XOOPS during authentication. The session look like this on my local debugger:
Beyond that, once you've included '/mainfile.php' at the top of any given php page, XOOPS sets up all kinds of nice object variables that contains important information. Specifically, there is an object called $XoopsUser that looks like this:
Notice that the 'vars' array contains both the user id and the hashed password of the current user. This is retained from page to page via the session. So, if a user comes to your XOOPS site, logs in, and then follows a link to another php page that, technically, isn't really apart of your XOOPS site, then all you need to do is include the mainfile.php file at the top of each of your php pages in your other application. You can then do things like:
to get access to these values.
For extra credit, if you've already gone to the trouble to add in an include for mainfile.php, you might as well give the site the appearance of being a XOOPS module. You can do this with 2 more lines. In general, you can wrap any html (or php) page into your XOOPS layout by doing the following:
Hope this helps...
Yes, there is a session created by XOOPS during authentication. The session look like this on my local debugger:
Beyond that, once you've included '/mainfile.php' at the top of any given php page, XOOPS sets up all kinds of nice object variables that contains important information. Specifically, there is an object called $XoopsUser that looks like this:
Notice that the 'vars' array contains both the user id and the hashed password of the current user. This is retained from page to page via the session. So, if a user comes to your XOOPS site, logs in, and then follows a link to another php page that, technically, isn't really apart of your XOOPS site, then all you need to do is include the mainfile.php file at the top of each of your php pages in your other application. You can then do things like:
$uid = !empty($xoopsUser) ? $xoopsUser->getVar("uid") : "";
$upw = !empty($xoopsUser) ? $xoopsUser->getVar("pass") : "";
to get access to these values.
For extra credit, if you've already gone to the trouble to add in an include for mainfile.php, you might as well give the site the appearance of being a XOOPS module. You can do this with 2 more lines. In general, you can wrap any html (or php) page into your XOOPS layout by doing the following:
<!-- This goes at the top of your html file -->
<?php
include_once '../mainfile.php'; // Load basic XOOPS environment (required).
include_once XOOPS_ROOT_PATH.'/header.php'; // Load page header (required).
?>
<!-- Whatever html or php content that is already in your file goes here -->
<!-- This goes at the bottom of your html file -->
<?php
include XOOPS_ROOT_PATH . '/footer.php'; // Load page foot (required).
?>
Hope this helps...
24
I've recently changed my default editor to the Tiny Editor. And I've actually changed the default editor for XOOPS too. There are instructions for doing this in the TinyEditor documentation (great PDF, by the way!) in the section titled "Making tinyeditor the default editor for Xoops"
Basically, you edit xoops/class/xoopsform/formddhtmltextarea.php and change the $htmlEditor variable so that it uses the tiny editor instead.
This sounded great, so I did it. But I was too quick to jump the gun. Because although this seems to work great, the default dhtml editor for XOOPS is now storing html in the database whereas before it was just storing text with bbcodes placed in it.
So now, for instance, whenever someone posts a comment on my site, they get the TinyEditor, type in some stuff, and see the HTML text (not translated by the browser but rendered as raw html text) on the screen.
Does anyone know how I can alter this behavior? I'm going to disable the TinyEditor as the default editor for the time being until I can understand better this process of storing and retrieving HTML to and from the database better.
Basically, you edit xoops/class/xoopsform/formddhtmltextarea.php and change the $htmlEditor variable so that it uses the tiny editor instead.
This sounded great, so I did it. But I was too quick to jump the gun. Because although this seems to work great, the default dhtml editor for XOOPS is now storing html in the database whereas before it was just storing text with bbcodes placed in it.
So now, for instance, whenever someone posts a comment on my site, they get the TinyEditor, type in some stuff, and see the HTML text (not translated by the browser but rendered as raw html text) on the screen.
Does anyone know how I can alter this behavior? I'm going to disable the TinyEditor as the default editor for the time being until I can understand better this process of storing and retrieving HTML to and from the database better.
26
You shouldn't be editing footer.php in the root of your XOOPS installation. That file is responsible for wrapping up the processing of the XOOPS environment and getting everything written to the screen.
Rather, what you want to do is edit the default theme (preferably, copy the default theme to a new theme and edit that instead). At the bottom of "\xoops\themes\default\theme.html" is a section devoted to the footer for every XOOPS output page. This is where you should put anything that you'd like to show up in your page's footer.
Also, if you don't see the new stuff show up right away, then you might try clearing out the "\xoops\tempaltes_c" folder, which contains cache data for your various pages.
Hope this helps...
Rather, what you want to do is edit the default theme (preferably, copy the default theme to a new theme and edit that instead). At the bottom of "\xoops\themes\default\theme.html" is a section devoted to the footer for every XOOPS output page. This is where you should put anything that you'd like to show up in your page's footer.
Also, if you don't see the new stuff show up right away, then you might try clearing out the "\xoops\tempaltes_c" folder, which contains cache data for your various pages.
Hope this helps...
27
I've had the same problem lately in that I cannot assign various things from the toolsets tab in the admin section for TinyEditor. This was because I had upgraded the the TinyMCE inside of TinyEditor to the latest version.
For what it's worth, I narrowed the 'problem' down to a specific plugin withing the new TinyMCE. You can upgrade every single folder to the new version of TinyMCE by copying the files over except for the "\modules\tinyeditor\editor\plugins\advlink" folder. This one is the one that seems to blow up the toolsets tab.
For me, I've simply decided to use the new advlink folder from the latest TinyMCE build anyway and keep the database updated by hand. Remember, the toolsets tab is simply a front end for data that gets stored in the database. If you want, it's fairly simple to just write the strings into the appropriate database fields yourself in order to get it working like you want. The table is 'xoops_tinyeditor_toolsets'. You have a row in this table for each group defined in Xoops. Rows 1 and 2 are associated with Webmasters and Registered Users respectively. You can update the memo fields for the tinyed_row1, tinyed_row2, and tinyed_row3 columns by hand, if necessary, by space separating the names of the plugins you'd like to appear on each row. Remember too that you might also need to include the plugin name in the activeplugs column too in order to get the functionality loaded (and cause the button to actually show up).
But like others here I eagerly anticipate the next release of TinyEditor!
For what it's worth, I narrowed the 'problem' down to a specific plugin withing the new TinyMCE. You can upgrade every single folder to the new version of TinyMCE by copying the files over except for the "\modules\tinyeditor\editor\plugins\advlink" folder. This one is the one that seems to blow up the toolsets tab.
For me, I've simply decided to use the new advlink folder from the latest TinyMCE build anyway and keep the database updated by hand. Remember, the toolsets tab is simply a front end for data that gets stored in the database. If you want, it's fairly simple to just write the strings into the appropriate database fields yourself in order to get it working like you want. The table is 'xoops_tinyeditor_toolsets'. You have a row in this table for each group defined in Xoops. Rows 1 and 2 are associated with Webmasters and Registered Users respectively. You can update the memo fields for the tinyed_row1, tinyed_row2, and tinyed_row3 columns by hand, if necessary, by space separating the names of the plugins you'd like to appear on each row. Remember too that you might also need to include the plugin name in the activeplugs column too in order to get the functionality loaded (and cause the button to actually show up).
But like others here I eagerly anticipate the next release of TinyEditor!
28
I figured out the answer to my problem. It seems that when the inline debug mode is activated in Xoops, it appends some HTML to the bottom of whatever PHP response streams go out from the server.
In the case of Tiny's Image and File Managers, this interfered with the 'language' scripts. Language.php was being called, but through the use of PHP's header statement, the stream being returned was actually a javascript document. With inline debug mode activated, some HTML was dropped in at the end of the javascript with no way to provide any context to it (in other words, the javascript parser doesn't know that the xoopslogger html is html and thinks of it as very poorly written javascript instead).
So the answer to all this was for me to turn off debug mode on my server!
---just living and learning :)
In the case of Tiny's Image and File Managers, this interfered with the 'language' scripts. Language.php was being called, but through the use of PHP's header statement, the stream being returned was actually a javascript document. With inline debug mode activated, some HTML was dropped in at the end of the javascript with no way to provide any context to it (in other words, the javascript parser doesn't know that the xoopslogger html is html and thinks of it as very poorly written javascript instead).
So the answer to all this was for me to turn off debug mode on my server!
---just living and learning :)
29
I'm probably going about this all wrong (I'm *sick* of staring at this!). Here's my 'real' problem.
I'm trying to integrate ImageManager and FileManger into TinyMCe. Then, I'd like to set it up so that when you upload files, you are doing so into user specific directories. Sounds simple, right? I've actually got everything running just fine on my local computer. When I try to get this running in my server environment, I get problems. It's the strangest thing, and I am literally at my wits end at this point.
So here's the deal: My local machine is the has a slightly different version of PHP running (PHP version 5.2.1 vs. 5.2.3 on the servers. On the servers, when I try to run ImageManager or FileManager, I get the error that you can read about in this forum thread.
I'm stuck because if I include mainfile.php, I'm stuck with errors on 5.2.3. If I don't include it, I can't set up the user specific directories.
Maybe I should try to downgrade the server's php version to see if that makes any difference. Any and all ideas or suggestions is greatly appreciated.
I'm trying to integrate ImageManager and FileManger into TinyMCe. Then, I'd like to set it up so that when you upload files, you are doing so into user specific directories. Sounds simple, right? I've actually got everything running just fine on my local computer. When I try to get this running in my server environment, I get problems. It's the strangest thing, and I am literally at my wits end at this point.
So here's the deal: My local machine is the has a slightly different version of PHP running (PHP version 5.2.1 vs. 5.2.3 on the servers. On the servers, when I try to run ImageManager or FileManager, I get the error that you can read about in this forum thread.
I'm stuck because if I include mainfile.php, I'm stuck with errors on 5.2.3. If I don't include it, I can't set up the user specific directories.
Maybe I should try to downgrade the server's php version to see if that makes any difference. Any and all ideas or suggestions is greatly appreciated.
30
This'll probably be a strange question, but here goes...
I would like to know the absolute shortest path to knowing the uid of the the currently signed on XOOPS User. I am not looking for something like this:
Yes, that's very short (in that it is only 2 lines of code), but is it really? Loading in mainfile.php causes lots of XOOPS plumbing to load in the background. That is not desirable (in my case), so I, instead, would like to do the following:
1) Attach to the database.
2) Read in the session information.
3) Determine who the currently logged in user is based on that session information.
I've been trying to piece this together for the past few minutes myself but keep including more and more 'stuff' in that ends up not being any different than just including mainfile.php in the first place (which, again, isn't desirable for me).
Even if I had to hard code some value in (db type, root name, root password, etc.), I wouldn't mind...just as long as I could get the session's uid without having to have the entire XOOPS API loaded to do so.
Hopefully, at least one of you out there will find this interesting enough to help me out!
Thanks!
I would like to know the absolute shortest path to knowing the uid of the the currently signed on XOOPS User. I am not looking for something like this:
require_once("mainfile.php");
echo $_SESSION['xoopsUserId']);
Yes, that's very short (in that it is only 2 lines of code), but is it really? Loading in mainfile.php causes lots of XOOPS plumbing to load in the background. That is not desirable (in my case), so I, instead, would like to do the following:
1) Attach to the database.
2) Read in the session information.
3) Determine who the currently logged in user is based on that session information.
I've been trying to piece this together for the past few minutes myself but keep including more and more 'stuff' in that ends up not being any different than just including mainfile.php in the first place (which, again, isn't desirable for me).
Even if I had to hard code some value in (db type, root name, root password, etc.), I wouldn't mind...just as long as I could get the session's uid without having to have the entire XOOPS API loaded to do so.
Hopefully, at least one of you out there will find this interesting enough to help me out!
Thanks!
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|