1
piar
Re: extgallery 1.04 - batch upload problems with this also
  • 2008/11/18 21:08

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


This is quite strange. Maybe you should uninstall extgallery ones more and send to server the oryginal module (probably you made some changes in source files and that is why you have that blank page).
The Fact that this one file was moved seems to be optimistic - but still there is something wrong and error messages during batch upload could give advice where is the problem.



2
piar
Re: extgallery 1.04 - batch upload problems with this also
  • 2008/11/18 18:17

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Oh yes - I forgot to write name of the file. But now - can you copy and paste that messages here?

This problem can be caused by some server settings - for example SAFE MODEhttp://php.net/features.safe-mode



3
piar
Re: extgallery 1.04 - batch upload problems with this also
  • 2008/11/18 15:37

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


So maybe for debuging purpose change 3 (sec.) delay to longer (for example 15 istead of three) in line 180:
redirect_header("photo.php"3sprintf(_AM_EXTGALLERY_X_PHOTO_ADDEDcount($photos)));

to have a possibility to copy error messages.

in line 104 of photo.php each photo is moved from /modules/extgallery/batch/ to /uploads/extgallery/public-photo/
Check permissions to that folder as well as for folders inside: large, medium, original, thumb. Also /modules/extgallery/batch/ is important - there should be probably set read and execute right for server process.



4
piar
Re: extgallery 1.04 - batch upload problems with this also
  • 2008/11/18 10:44

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Are there some error messages (errors reporting could be set up in general settings) during that batch upload?
As I wrote in your previous topic I'm using that version of ext on 2.3.1 and it works for me. So it could be something with your configuration - and I think that error messages may help.



5
piar
Re: gallery module that works with 2.3??
  • 2008/11/17 22:52

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


I'm using eXtGallery 1.04 on 2.3.1 and there is that (KO) written in index page but everything works correct (also batch upload).



6
piar
Re: WF-Channel Permissions problem
  • 2008/11/17 14:34

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Thank you for response!

So maybe I'll put here what I've done to solved it because I think this could be general problem with all modules basing on WF-Resource.
In three places in file modules/wfresource/class/class.objecthandler.php there is a code:
if ( $this->doPermissions ) {
  
$sql .= ' AND ' $criteria->render();
} else {
  
$sql .= ' ' $criteria->renderWhere();
}

I've changed it to:
if ( $this->doPermissions ) {
  if (
$criteria->render() !== "") {
    
$sql .= ' AND ' $criteria->render();
  }
} else {
  
$sql .= ' ' $criteria->renderWhere();
}


And now it works correct not only for useres from first group (default Webmasters group).



7
piar
Re: WF-Channel Permissions problem
  • 2008/11/17 12:15

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Maybe this could help in helping me ;)
When I enter 'Admin index' as admin then queries looks like:
SET NAMES 'utf8' 
SELECT FROM xaa2_config WHERE (conf_modid '0' AND conf_catid '1'ORDER BY conf_order ASC 
SELECT sess_data
sess_ip FROM xaa2_session WHERE sess_id 'bd4af262d1daa6f5ab56ded6b312a3f3' 
SELECT FROM xaa2_users WHERE uid '1' 
DELETE FROM xaa2_protector_access WHERE expire UNIX_TIMESTAMP() 
SELECT COUNT(*) FROM xaa2_protector_access WHERE ip='83.20.40.84' AND request_uri='/modules/wfchannel/admin/index.php' 
SELECT COUNT(*) FROM xaa2_protector_access WHERE ip='83.20.40.84' 
INSERT INTO xaa2_protector_access SET ip='83.20.40.84',request_uri='/modules/wfchannel/admin/index.php',expire=UNIX_TIMESTAMP()+'60' 
SELECT FROM xaa2_modules WHERE dirname 'wfchannel' 
SELECT FROM xaa2_config WHERE (conf_modid '8'ORDER BY conf_order ASC 
SELECT 
FROM xaa2_modules WHERE dirname 'wfresource' 
SELECT FROM xaa2_wfcpages  
SELECT 
FROM xaa2_wfcpages ORDER BY wfc_cid DESC LIMIT 010 
SELECT 
FROM xaa2_group_permission WHERE (gperm_name 'module_admin' AND gperm_modid '1' AND (gperm_groupid '1' OR gperm_groupid '2')) 
SELECT FROM xaa2_modules WHERE (hasadmin '1' AND isactive '1'ORDER BY weight ASCmid ASC 
SELECT 
FROM xaa2_modules WHERE dirname 'news' 
SELECT FROM xaa2_config WHERE (conf_modid '13'ORDER BY conf_order ASC 
SELECT 
FROM xaa2_wfcrefers


And when I do the same as that editor I get:
SET NAMES 'utf8'
SELECT FROM xaa2_config WHERE (conf_modid '0' AND conf_catid '1'ORDER BY conf_order ASC
SELECT sess_data
sess_ip FROM xaa2_session WHERE sess_id '6b48e35c932e7660fd20a3e1f0dd9cb1'
SELECT FROM xaa2_users WHERE uid '2'
SELECT COUNT(*) FROM xaa2_group_permission WHERE (gperm_modid '1' AND gperm_name 'module_admin' AND gperm_itemid '1' AND (gperm_groupid '4'))
SELECT COUNT(*) FROM xaa2_group_permission WHERE (gperm_modid '1' AND gperm_name 'module_admin' AND gperm_itemid '1' AND (gperm_groupid '4'))
DELETE FROM xaa2_protector_access WHERE expire UNIX_TIMESTAMP()
SELECT COUNT(*) FROM xaa2_protector_access WHERE ip='83.20.40.84' AND request_uri='/modules/wfchannel/admin/index.php'
SELECT COUNT(*) FROM xaa2_protector_access WHERE ip='83.20.40.84'
INSERT INTO xaa2_protector_access SET ip='83.20.40.84',request_uri='/modules/wfchannel/admin/index.php',expire=UNIX_TIMESTAMP()+'60'
SELECT FROM xaa2_modules WHERE dirname 'wfchannel'
SELECT COUNT(*) FROM xaa2_group_permission WHERE (gperm_modid '1' AND gperm_name 'module_admin' AND gperm_itemid '8' AND (gperm_groupid '4'))
SELECT FROM xaa2_config WHERE (conf_modid '8'ORDER BY conf_order ASC
SELECT 
FROM xaa2_modules WHERE dirname 'wfresource'
SELECT FROM xaa2_wfcpages c LEFT JOIN xaa2_group_permission l ON l.gperm_itemid c.wfc_cid WHERE l.gperm_name 'wfc_page' AND l.gperm_groupid IN ) ) AND
Error number1064
Error message
You have an error in your SQL syntaxcheck the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
SELECT DISTINCT c
.* FROM xaa2_wfcpages c LEFT JOIN xaa2_group_permission l ON l.gperm_itemid c.wfc_cid WHERE l.gperm_name 'wfc_page' AND l.gperm_groupid IN ) ) AND ORDER BY wfc_cid DESC LIMIT 010
Error number
1064
Error message
You have an error in your SQL syntaxcheck the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDER BY wfc_cid DESC LIMIT 0, 10' at line 1
SELECT 
FROM xaa2_group_permission WHERE (gperm_name 'module_admin' AND gperm_modid '1' AND (gperm_groupid '4'))
SELECT FROM xaa2_modules WHERE (hasadmin '1' AND isactive '1'ORDER BY weight ASCmid ASC
SELECT 
FROM xaa2_modules WHERE dirname 'news'
SELECT COUNT(*) FROM xaa2_group_permission WHERE (gperm_modid '13' AND gperm_name 'news_submit' AND (gperm_groupid '4'))
SELECT FROM xaa2_config WHERE (conf_modid '13'ORDER BY conf_order ASC
SELECT 
FROM xaa2_wfcrefers


Isn't it some core error?
What should I do to gain ability to have that editors group for managing only contents? Now it doesn't work because of that problem with 'Admin index' of WF-Channel :(



8
piar
WF-Channel Permissions problem
  • 2008/11/13 21:46

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


I'm using XOOPS 2.3.1 with WF-Channel 2.02 and have some problem with permissions.
I created a group called 'editors' which have granted full permission to that module. But users from that group don't see any page in 'Admin index' - they still have message: No Pages Available. Even when editor creates new page (which admin see in his 'Admin index') it doesn't appear in 'Admin index' of editor. When I put page editing address as editior (like: modules/wfchannel/admin/index.php?op=edit&wfc_cid=19) he can edit that page and save changes...

What could cause that editors don't see pages list ('Admin index')?



9
piar
Re: Using SSL with Xoops
  • 2008/11/13 14:16

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Thanks for that suggestions!
It is as you wrote - cache mechanism don't go well with http/https switching (but probably there are problems only with that Admin panel).
Maybe it is not a perfect solution - but I made changes that disabled that cache and now it works as I expect. If someone has same problem, here is what I've done:
In modules/system/class/gui/default/default.php in function loadMenu() I've commented out everything and put there:
return $this->generateMenu();

and in function generateMenu() I've changed last lines like this:
//xoops_load("cache");
//XoopsCache::write("adminmenu_" . __CLASS__, $modules);
return $modules// added


So now that menu works without using cache.



10
piar
Re: Using SSL with Xoops
  • 2008/11/13 10:27

  • piar

  • Just popping in

  • Posts: 22

  • Since: 2008/10/30


Thanks for that instruction TheFinni - it is really very helpful and I agree that this should be built in to the core.

I just have one problem with this - it is about cache.
After that changes in mainfile.php when I login using SSL everywhere I have links beginning with 'https' except that ones in Administration menu for administering modules (ex. System->Banners, System->Block etc.). They are still 'http' and I've found that they are cached in file: xoops_data/caches/xoops_cache/xoops_adminmenu_XoopsGuiDefault.php.
Is it somehow possible to disable that caching mechanism - so when I enter Admin panel with http I'll get http links, and when with https - https links?




TopTop
(1) 2 3 »



Login

Who's Online

154 user(s) are online (108 user(s) are browsing Support Forums)


Members: 0


Guests: 154


more...

Donat-O-Meter

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

Latest GitHub Commits