41
sceilig
Re: problem including a smarty file
  • 2006/3/20 10:43

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


Quest,
That didnt work for me. However, I did get it to work in a sortof convoluted way, by closing the php tag before including the smarty file, and then opening the php tag again.

Quote:

<{php}>
global $xoopsUser;
if ($xoopsUser) {
$groups = $xoopsUser->getGroups();
$special_group_id = 4;
if (in_array($special_group_id,$groups)) {
<{/php}>
<{include file="default/navigation/theme_adminnav_special.html"}>
<{php}>
} else {
<{/php}>
<{include file=""default/navigation/theme_adminnav.html"}>
<{php}>
}
}
<{/php}>


Surely there is a more elegant way of doing this?



42
sceilig
problem including a smarty file
  • 2006/3/19 22:18

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


I am trying to include a different admin navigation theme file depending on the permissions of the administration group logged into the backend area. I tried doing the code with just smarty but had difficulty, so I thought I could make it happen using php. However, when I try and include a file containing smarty code, it doesnt render it correctly - the smart code in the included files gets displayed to the browser.

What am I doing wrong, and also, how could the below be performed using just smarty coding?

Quote:

<{php}>
global $xoopsUser;
if ($xoopsUser) {
$groups = $xoopsUser->getGroups();
$special_group_id = 4;
if (in_array($special_group_id,$groups)) {
include("../../themes/default/navigation/theme_adminnav_special.html");
} else {
include("../../themes/default/navigation/theme_adminnav.html");
}
}
<{/php}>


Note, I also had to use relative paths to include the theme files which doesnt seem right - smarty includes them like
<{include file="default/navigation/theme_adminnav.html"}>



43
sceilig
Re: How to change or hack default xoops editor?
  • 2006/3/14 11:01

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


steinj14,
Im in the same boat as you, and I think there are a lot of others squeezed into this "how to change the default editor" boat. I too have searched long and hard through the forums for a good solution but it appears to be vague.

I do acknowledge that not all modules are compliant with the wysiwyg editors so changing the default editor might cause problems with some modules? What I dont understand is why this editor was chosen as "default" in the first place - Ive used a plethora of wysiwyg textarea editors with no trouble but this default editor aint one bit user friendly. If spaw, fckeditor or tinymce were chosen as the default one then I think there would be a lot less frustration for many XOOPS users.

Some modules allow you to change the editor in the module preferences but other modules like Extended Profiles do not. I have been tinkering with the code for that module but as yet havent been able to switch the editor.

I feel the code may be similar to the one described in this XOOPS hack
https://xoops.org/modules/news/article.php?storyid=2597
Quote:

==== HACK ====================================
In /modules/system/blocks/system_blocks.php
around line 56, you will find the following line:

$form->addElement(new XoopsFormDhtmlTextArea(_MB_SYSTEM_CONTENT, 'options[0]', htmlspecialchars($ts->stripSlashesGPC($options[0]), ENT_QUOTES), 15, 60));


Change it to:

$theEditor = new XoopsFormWysiwygTextArea(array());
$theEditor->setName('options[0]');
$form->addElement($theEditor);

================================================



If would be wonderful if one of you XOOPS experts could help us and many others with a detailed way of going about changing the default editor in a module or systemwide.

thanks!



44
sceilig
Re: Multisites Module/Hack
  • 2006/3/3 8:26

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


It seems the problem I had with extracting the multisites module file was my own. Usually I tar -xzvf filename.tar.gz but that didnt gave me errors on Mithrandir's file. Instead I did a gunzip and tar -xvf and it extracted fine. Thanks for the help on that.

nbecu, the whole purpose of the multisite module was to have one source code driving multiple websites.

Here is Mithrandir's explanation:

Quote:

You first have to understand that basics of how this hack works.

It works by running ALL sites from the SAME code. For example, I have www.bfsb.dk pointing to the same physical location as xoops.web-udvikling.dk, so it is the SAME index.php that is accessed.

You can do it with subfolders on Apache with the ALIAS directive in the apache's httpd.conf file, making an alias for the (non-existing) subfolder to point to the root.

In your example, you would

1) install XOOPS on 127.0.0.1
2) install site administration on this site.
3) Create a new site in the site administration module, with the URLhttp://127.0.0.1/humor and the prefix zxcvb
4) Create an ALIAS in your apache's httpd.conf file
5) Restart apache
6) access 127.0.0.1/humor and start configuring this site. The first thing I do is to change the name of the site in the site's normal XOOPS general preferences and then I uninstall the Site admin module from this site to avoid confusion

To install a module and share it with other sites do this:
1) Install module on all the sites that should have the module - include the "base" site (127.0.0.1/ in your case)
2) Edit each site in the "base" site's Site Administration module to share the new module's tables

To uninstall a shared module from a subsite do this:
1) Edit the subsite in the "base" site's Site Administration and set the module's tables to not be shared anymore
2) Uninstall the module on the subsite

Especially the uninstallation procedure can cause problems if you don't un-share the tables first (since the tables will then be removed by the uninstallation - but all the other subsites will still have references to the module in their database tables)



45
sceilig
Re: Multisite HACK for 2.2.3 Final
  • 2006/3/3 8:11

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


I was wondering the same thing about the Multisite module - the single database versus a database for each subsite.

I plan on having 200 community sites all spawned off the master XOOPS website and would prefer each site to have its own database. If I dont share tables between the sites then I would be looking at a database with 200x100 tables = 20,000 tables!!!!

Im not too familiar with how MySQL handles load but which would perform better - 200 separate databases Vs 1 database with tables for 200 sites?? Any MySQL experts out there?

As for the commercial mambo/joomla multisites module developed by ElearningForce DK, it does look pretty slick and powerful to handle the whole creating/managing of subsites. However Ive decided to go with XOOPS to accomplish my project for varied reasons.



46
sceilig
Multisites Module/Hack
  • 2006/3/1 11:20

  • sceilig

  • Just popping in

  • Posts: 53

  • Since: 2006/3/1 1


I have searched through the forum and Google for a Xoop module that would manage multisites/subsites but didnt come up with much.
I did see a modules posting by Mithrandir (Jan Pedersen) but the downloaded tar file containing the module is corrupt.
http://xoops.web-udvikling.dk/modules/wfdownloads/viewcat.php?cid=1

Does anyone happen to have a valid copy of the .tar file for this module, or perhaps some direction as to where I might find more info/module for a XOOPS multisite solution.

thanks!




TopTop
« 1 2 3 4 (5)



Login

Who's Online

134 user(s) are online (81 user(s) are browsing Support Forums)


Members: 0


Guests: 134


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits