XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. XOOPS Community Support forums / 
  3. 2.5.x Support 
  4.  / XOOPS 2.5.7 Final Release Issues
Register
31
Mamba
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/19 17:21

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
is likely to be revised the publisher module for this version of xoops

?????
What is going to be revised?
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
32
Mamba
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/19 17:24

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
- my extgallery effects not working
- publisher tabs when submit article not working - no tabs ...

Did you updated the System module? Did you clear the Cache?

What version of extGallery and Publisher do you have?
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
33
slider84
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/19 17:52

  • slider84

  • Just popping in

  • Posts: 21

  • Since: 2013/8/16


Hi Mamba,

Quote:
Did you updated the System module? Did you clear the Cache?

No updates for me: Brand new Xoops 2.5.7 (with protector and default theme)+ fresh install of Publisher.
Quote:
publisher tabs when submit article not working - no tabs
Tabs ok in submit form

No tabs in administration section (ex:Edit un article)
In FF console: two errors
[10:07:28,345] TypeError: $.browser is undefined @ http://mysite/modules/publisher/js/ui.core.js:13
[10:07:28,345] TypeError: $.widget is not a function @ http://mysite/modules/publisher/js/ui.tabs.js:608


Link to publisher that i used
34
Mamba
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/19 20:23

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


Quote:
No updates for me: Brand new Xoops 2.5.7 (with protector and default theme)+ fresh install of Publisher.

Thanks, I'll look into it....
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
35
timgno
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/19 23:21

  • timgno

  • Module Developer

  • Posts: 1504

  • Since: 2007/6/21


I updated and my hacks have been deleted,

You can consider this my hack in the future?
Footer Blocks

In addition I have these three notices:
Quote:

Notice: Undefined index: 11 in the file /class/theme_blocks.php line 123
Notice: Undefined index: 12 in the file /class/theme_blocks.php line 123
Notice: Undefined index: 13 in the file /class/theme_blocks.php line 123
36
Mamba
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/20 0:17

  • Mamba

  • Moderator

  • Posts: 11409

  • Since: 2004/4/23


We've issued a small patch for couple of issues:
- fixed link to include
- added mainfile.php in /extras for people who have problems with creating the file

Please download it from: SourceForge File Repository
Support XOOPS => DONATE
Use 2.5.11 | Docs | Modules | Bugs
37
timgno
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/20 0:45

  • timgno

  • Module Developer

  • Posts: 1504

  • Since: 2007/6/21


is not clear from the maintenance side folder smarty_compile
38
ipwgc
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/20 4:35

  • ipwgc

  • Quite a regular

  • Posts: 216

  • Since: 2005/8/13


Hi Mamba,
I report a small problem, but I think it's important.
First, I update the spanish version 2.5.6 from package 2.5.6 to 2.5.7.

When we give permission to the groups from the manager the problem appears. see below
Quote:

Warning: include_once(/home/xxxxxxx/public_html/modules/system/admin../../../include/cp_header.php) [function.include-once]: failed to open stream: No such file or directory in /home/liberart/public_html/modules/system/admin/groupperm.php on line 4
Warning: include_once() [function.include]: Failed opening '/home/xxxxxx/public_html/modules/system/admin../../../include/cp_header.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/liberart/public_html/modules/system/admin/groupperm.php on line 4
Fatal error: Call to undefined function redirect_header() in /home/xxxxxx/public_html/modules/system/admin/groupperm.php on line 9


I compare and review files in the two versions, 2.5.6 and 2.5.7
system/admin/groupperm.php on line 4
THIS IS VERSION 2.5.6 SEE LINE 4
Quote:
// $Id: groupperm.php 10981 2013-02-04 19:37:48Z trabis $

include '../../../include/cp_header.php';
$modid = isset($_POST['modid']) ? intval($_POST['modid']) : 0;

// we dont want system module permissions to be changed here
if ($modid <= 1 || !is_object($xoopsUser) || !$xoopsUser->isAdmin($modid)) {
redirect_header(XOOPS_URL.'/index.php', 1, _NOPERM);
exit();



THIS IS VERSION 2.5.7 SEE LINE 4 IT DIFFERENT FROM THE OTHER VERSION
system/admin/groupperm.php on line 4
THIS IS VERSION 2.5.6 SEE LINE 4
Quote:
// $Id: groupperm.php 12620 2014-06-19 21:07:49Z beckmi $

include_once dirname(__FILE__) . '/../../../include/cp_header.php';
$modid = isset($_POST['modid']) ? intval($_POST['modid']) : 0;

// we don't want system module permissions to be changed here
if ($modid <= 1 || !is_object($xoopsUser) || !$xoopsUser->isAdmin($modid)) {
redirect_header(XOOPS_URL.'/index.php', 1, _NOPERM);
exit();


I can upload the file from the previous version, but it's better for you to check and search for the solution to the problem

THIS NOTE IS FOR ANGELO ROCHA.
Angelo, do you have some upgrade for thema "serenityorange" in xoops version 2.5.7?
THIS IS THE SPANISH SITE VERSION 2.5.7

Regards,
DAVID
39
slider84
Re: XOOPS 2.5.7 Final Release Issues

  • 2014/6/20 7:57

  • slider84

  • Just popping in

  • Posts: 21

  • Since: 2013/8/16


I have a small problem with the following link in protector (tab 'security advisory')

That check PHP files inside TRUST_PATH are set to read-only (it must be 404.403 or 500 error)

The link points to:
http://myserver/www/xoops_lib/modules/protector/public_check.php
(or http://localhost/www/xoops_lib/modules/protector/public_check.php for local installation)

but have to point to:
http://myserveur/xoops_lib/modules/protector/public_check.php
There are additionnal www.

My analysis after several tests and fresh install:
This occurs only if 2.5.7 is installed (not tested with 2.5.6) on a debian based server
(I do not have any other Linux distributions to test) in local or intranet.
In my case, tested on two different machines:
- Ubuntu 12.04 LTS server with PHP 5.3.10 and Apache 2.2.22.
- Debian 7 with PHP 5.4.4 and Apache 2.2.22.
- Default LAMP installation under / var / www (Hey, it looks like the three additionnal w)

So far nothing special and a website works perfectly here.

If I install a 2.5.7 at this point, I have the problem of protector link which does not work with the additionnal www.
But if I create a subdirectory (with the well alias) eg / var/www/site1 and I install 2.5.7 here the protector link is good.
I'd like to know if anyone else has the same problem on a LAMP configuration or if someone could test to confirm whether or not the problem is in protector or the configuration of my machines?
40
geekwright
Re: XOOPS 2.5.7 Final Release Issues

Quote:

slider84 wrote:
I have a small problem with the following link in protector (tab 'security advisory')

That check PHP files inside TRUST_PATH are set to read-only (it must be 404.403 or 500 error)

...


This is definitely configuration related, and definitely not a new issue with 2.5.7.

Protector is comparing the XOOPS_ROOT_PATH and XOOPS_TRUST_PATH and trying to use the difference to build a directory traversal that can be used in a URL. The URLs only show us where it ended up, not how it got there. For that we need the actual directory paths.

I'll use Ubuntu 12.04 LTS as a point of reference since I have it available. The default web site is at /var/www. If we define a www directory under that, the paths of everything underneath will have two 'www' components in the full directory, so the match might get confused. It should also get confused if you add a 'var' directory.

Ideally, xoops_lib should be completely outside of /var/www (or whatever the root is,) and protector will be unable to build a URL to it. If for some reason it has to be inside the web root, a .htaccess file that restricts the web access will be better than leaving it completely exposed. Usually protector can build a URL to that, and the test will determine if the .htaccess is actually working.

Since protector has internal knowledge of both paths, it ideally should be able to reliably determine the needed traversal. But this also highlights the need for real human analysis of the conditions, and protector's broken image test is a poor substitute for that.

One could devise a new test that did something more sophisticated, possibly testing multiple variations with curl and checking the return codes instead of asking the user to verify that an image link doesn't work. But it still won't beat proper setup and human analysis.
« 1 2 3 (4) 5 6 7 8 »

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

335 user(s) are online (255 user(s) are browsing Support Forums)

Members: 0

Guests: 335

more...

Donat-O-Meter

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

Latest GitHub Commits