131
skalpa
Re: Weblinks module security problem. Patch available ?
  • 2003/12/22 14:04

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


If you look at the article you'll see that it's been published today and I'm just waking up: that's the reason why a patch hasn't been released yet...

Also, this site is not vulnerable to this problem. The sample in the security advisory is just informative. Entering an url manually like this would just allow you to hijack your own account, so you can make people believe you are yourself (pretty deep sentence, isn't it )

This is considered a security problem, as people are allowed to add links to the mylinks section.
However, here:
- The auto-approve option is set to off. So any such link would be deleted by an admin before it is published
- We don't use the frame feature either

So if you feel concerned about this issue, turn one of those 2 options off until I can get a coffee, I'll be working on it after

Skalpa.>



132
skalpa
Re: custom theme per module
  • 2003/12/20 14:21

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
I think I should also remove the current css file from theme.html in order to make it work.


Normally you don't have to, but that's where the difficulties appear...
If you keep both css, the values you set in the 2nd one will override the ones in the 1st one. So you should try keeping the xoops_themecss declaration 1st and insert the module specific one after (again, that's the order I used for 2.1).

So, if you do things like this
In style.css:
.
itemHead {padding3pxbackground-color#2F5376; color: #FFFFFF; }

In modules/news/style.css:
.
itemHead background-color#ff0000; }


The news module "itemHead" elements will have a red background, but the color will stay white (as defined in the 1st stylesheet).
As I said this may get a little tricky to manipulate depending on the way you use the stylesheets, but you should really do it like this (define "common" rules in the main css, and (re)define custom properties in the mod css).

Skalpa.>



133
skalpa
Re: custom theme per module
  • 2003/12/20 12:26

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Other solution (shorter): you can add this php block at the top of your template.
<{php}>
$mod $GLOBALS['xoopsModule'];
$modvar = array( 'dirname' => (isset($mod) ? $mod->getVar('dirname') : 'system') );
$GLOBALS['xoopsTpl']->assign'xoops_module'$modvar );
<{/
php}>


Then you can get the name of the current module using:
<{$xoops_module.dirname}>


And last, if you want to insert a module dependent css, you should create modules/modulename/style.css within your theme folder, and insert it using something like this:
<link rel="stylesheet" href="<{xoops_imageurl}>modules/<{$xoops_module.dirname}>/style.css" />


The good point is that this simulates the next release behavior, so doing like this you'll just have to remove the php block and the link tag from your theme to make it work with the new version.
The bad point is that this might change before the final version (I don't think so actually, but...)

Skalpa.>



134
skalpa
Re: Xoops.org theme & banners
  • 2003/12/20 9:29

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
Thank you, however the default is NOT the same theme as this current site.


It's just a slightly modified version of the default theme...

Be our guest, help yourself

Skalpa.>



135
skalpa
Re: Porting Postnuke Module to Xoops
  • 2003/12/20 2:37

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Your problem (I believe) is coming from the fact that some files (like header.php) assume they are included from the global scope (so they just create variables without using $GLOBALS['varname']=stuff thinking those will become global vars).
Right now there's no real solution to solve this (that's one we should look at, but even if it's not a difficult one there are a lot of things to change).

So the only thing you can try is "without the function":
If your if block is not inside an "openCMSHeader()" function, you can try doing:
if ( $is_xoops ) {
    include 
XOOPS_ROOT_PATH 'header.php';
} elseif ( 
$other_cms ) {
    
otherCMSOpen();
}


otherwise I guess there's no solution right now (to be exact: I'm not able to find one )

Skalpa.>
PS: Sorry for the not so long but not really useful answer



136
skalpa
Re: How to mark Required XoopsForm Element?
  • 2003/12/15 13:21

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
Can anybody tell me why it does work and what is the correct code?


1) It doesn't work because the XOOPS function that transforms the form elements to template variables doesn't take care of the "required" flag (you only have access to name / caption / body and hidden).
2) There is no correct code

The only solution I would have for now would be:
- Wait for 2.1 next year (this will be possible, but I changed almost everything in the form framework so I can't just tell you to grab the modification from the CVS tree)
- If you're doing your own module, implement a XoopsForm child class, overload the assign() method, and use your class instead of XoopsThemeForm or whatever you use

Skalpa.>



137
skalpa
Re: reading an array value from xoops_version.php
  • 2003/12/10 12:15

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


echo var_dump( $xoopsModule->getInfo('tables') );



Skalpa.>



138
skalpa
Re: version 2.05
  • 2003/12/7 22:55

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
What is cached in the /cache directory?


If uploading the files again didn't work, it should come from a bad template somewhere

you can try this:
1) Kill the content of /cache
(except adminmenu.php maybe, but it will be recrated the next time you go to admin.php, so whatever...)
2) Clean /templates_c (but you already did this...)
3) If that wasn't enough, update the system module in the system admin / modules to force the recompilation of all the templates from the files.

Skalpa.>



139
skalpa
Re: Slow Loading of XOOPs (General Question)
  • 2003/12/7 22:44

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
My question is basically this: why to do these PHP-based CMS systems take so long to load and log in?


Most of the time these delays are related to the connection between your server and its DB server. Some share host companies really load their db servers with too many sites.
As Herko said, caching data may help, but generally the delay happens when php is trying to get the connection, not during the page processing by itself, so not always.
Best solution is to find a better host.

Quote:
I've installed some Access-based ASP front ends and they always load in a snap. I can't believe that Access and ASP are inherently better.... in fact, I have heard the opposite


Hehehe.
1) I've worked a lot using the asp/ms platform, and it is a good one.
2) Access is faster. But an access DB is a file stored somewhere on your server, and you're the only one to aceess it, so we're not talking about the same thing.
This system will never support more than 20 simultaneous connections (even if the MS documentation says 255 )

Quote:
My next question is this: should I get dedicated server

I think finding a hosting company with good shared plans would be enough, but I'm sorry I can't personally help you here, maybe someone will.



140
skalpa
Re: Is it possible to check for a pagetype within my theme
  • 2003/12/5 6:45

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


Quote:
Skalpa.. next time please press 'reply' instead of 'edit'



Sorry m8s, I just made this answer before going to sleep. Looks like I really needed it
(and in fact I made 2 posts yesterday night, I just hope I didn' do the same with the 2nd one )

For the "pagetype" by itself, there is a variable that modules should set but all of them don't do it. However I think this should work (at least for the users page). Add these lines at the end of the php block I gave above.
if ( isset( $GLOBALS['xoopsOption']['pagetype'] ) ) {
    
$GLOBALS['xoopsTpl']->assign('pagetype'$GLOBALS['xoopsOption']['pagetype'] );
}


Sorry again

Skalpa.>




TopTop
« 1 ... 11 12 13 (14) 15 16 17 ... 19 »



Login

Who's Online

141 user(s) are online (82 user(s) are browsing Support Forums)


Members: 0


Guests: 141


more...

Donat-O-Meter

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

Latest GitHub Commits