11
dejadingo
Re: Most current Xoops 2.5.11
  • 2021/9/27 12:54

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


@Mamba: Thanks, that's much closer to your fork than the version I initially found, not quite sure how.

Is there a standard set of System/Unit tests and a test environment I can install, other than just my local server installation?



12
dejadingo
Most current Xoops 2.5.11
  • 2021/9/25 17:58

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


Can anyone say what is the most current version of Xoops 2.5.11?

I would like to test/use ModuleBuilder version 3.x but the description seems to indicate it only works with Xoops 2.5.11. It looks like the Master version still reports itself as 2.5.10 while the Beta-2 version posted by Mamba reports itself as 2.5.11, and many files in the Beta-2 version seem more correct than those from the Master.

Thanks for the assistance.



13
dejadingo
Upgrade my own modules to 2.5.10 and Xmf
  • 2019/7/30 20:28

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


I'm currently upgrading my own handful of simple modules to Xoops 2.5.10. Some are pretty old, and I would like to have a consistent admin side as well as position them to move forward easily in future.

Can someone point me to an existing module that takes full advantage of Xmf that I can use as an example? It can even be something working with the upcoming new Xoops version. I just want to see a complete basic implementation.

Thanks,
Sherry



14
dejadingo
Re: PRECHECK resursion in protector
  • 2014/12/15 15:47

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


It also seems we need to add the protection
if (defined('PROTECTOR_{PRE|POST}CHECK_INCLUDED')) return;

at the top of both precheck.inc.php and postcheck.inc.php to avoid the constant page error for trying to redefine PROTECTOR_POSTCHECK_INCLUDED since both of these files are also included by functions in core.php.



15
dejadingo
PRECHECK resursion in protector
  • 2014/12/15 0:36

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


Here's one I did not expect to find.
I'm testing out a new site using Xoops 2.5.7.1 (PHP 5.4.27) and I have installed the Common Utilities (2.2.75) so that I can try out bitcero's QuickPages. The problem I have encountered comes when you try to hide the Common Utilities module from the Main Menu. In the protector's precheck.inc.php we find:
require_once dirname(__FILE__).'/precheck_functions.php' ;

  if( 
class_exists'Database' ) ) {
     require 
dirname(__FILE__).'/postcheck.inc.php' ;
     return ; }

  
define('PROTECTOR_PRECHECK_INCLUDED' ) ;

When I hide other modules like User Profile, or Private Messaging, it does not appear that the Database class exists, so we turn on PROTECTOR_PRECHECK_INCLUDED, and proceed with the rest of the code in that file. When hiding Common Utilities, the Database class apparently exists, and we try to load the postcheck.inc.php file. Unfortunately this starts an infinite recursion because PROTECTOR_PRECHECK_INCLUDED has not yet been defined and we go back to loading precheck.inc.php.

If I change precheck.inc.php to move
define('PROTECTOR_PRECHECK_INCLUDED' ) ;
above the check for the Database class, this gets the flag set before we need it to prevent the resursion.



16
dejadingo
Calling XoopsModule->getAdminMenu() from multiple files
  • 2009/1/2 0:17

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


I've been working on CPanel themes over the holidays, and here is an issue that's caused me a lot of headaches and for which I finally isolated the source.

If you create module instances with code from different files while you are building a CPanel theme, the first call to getAdminMenu() for a module will return the menu, but subsequent calls *from different files* will always get an empty menu.

This is happening because the second time you call the method, PHP knows you have already loaded the module's adminmenu file and does not load it again. However, when a module instance is being created and initialized in a different file we need to load the adminmenu file in order to get the $adminmenu array with which to initialize the adminmenu property of the module.

I noticed that MusS seems to have tripped on this issue in his lovely ThAdmin module, but the patch at the end of xoops_thadmin_cp_header() was not sufficient to fix my problems. I really think this is a bug in the XoopsModule class, and it makes incremental development of CPanel themes very difficult. Here's the hack I am currently using on my systems. It's a simple change, and I'd like to hear if anyone thinks this should *not* be generally adopted for the XOOPS core.

/**
     * Load the admin menu for the module
     */
    
function loadAdminMenu()
    {
        if (
$this->getInfo('adminmenu') && $this->getInfo('adminmenu') != '' && file_exists(XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu'))) {
// -DJD-
//
//        Make sure we actually load the module's menu (if there is one).
//
//        Using 'include_once' prevents menu initialization when subsequent
//            calls to getAdminMenu() are made from within independent files
//            during the same execution.  A good example is when CPanel menu
//            construction is shared between methods in the XoopsSystemGui
//            subclass and functions in an included cp_functions.php file.
//        PHP loads the file in the context of the first call, but since new
//            instances of XoopsModule are created for use in each independent
//            file's functionality, all subsequently instantiated XoopsModule
//            instances do not have an adminmenu.
//
//            include_once XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu');
            
include XOOPS_ROOT_PATH.'/modules/'.$this->getVar('dirname').'/'.$this->getInfo('adminmenu');
//
// -DJD-
            
$this->adminmenu =& $adminmenu;
        }
    }



17
dejadingo
Re: Blocks in wrong order for ANON USERS ONLY on top page after 2.3.2a upgrade
  • 2008/12/19 5:56

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


Thanks so much for finding this. It's certainly an obscure SQL issue, likely due to the WHERE clause construction [WHERE m.block_id=b.bid].

Whoever fixes Tracker issue #2414383 should probably make the same change in line 471 since it has an identical WHERE clause in line 491. I don't have access to update the Tracker issue.



18
dejadingo
Re: Group Permission management and Xoops 3
  • 2008/6/8 16:05

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


OK. So nobody else is currently working on this, but you consider it an appropriate possible core extension?

I know it's not officially blessed, but are there enough people using the 2.3.2 branch that simple sites reasonably might use it? I can put that up on my test site, but it will probably get more action if I put one of my sites up using it instead of the 2.0.18.1 that is currently running.

Thanks, I'll keep watching for XOOPS 3 tarball.



19
dejadingo
Re: Group Permission management and Xoops 3
  • 2008/6/8 15:42

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


Sorry. I just edited my post. I'm talking specifically about group permissions here.

There are several modules that go to extreme lengths to provide their own module specific group permission settings, with onInstall SQL inserts and by cloning system files and tweaking them. myAlbum-P is one of them. I want to provide a standard mechanism for
1) adding a module's permissions without the file cloning, and possibly without the onInstall by extending the $modversion array
2) plugging the management of these permissions into the system-wide group permission management

In addition, I want to use config option categories for my own modules and give permission to specific user groups for certain categories. xfguestbook contains a start on the config categories issue, and I have a hack that I can use to plug that into the standard xoops_version.php file in XOOPS 2.2. But even that does not address my desire to permit the categories for only certain groups.

Thanks.

---
Any info on access to the XOOPS 3 code?



20
dejadingo
Group Permission management and Xoops 3
  • 2008/6/8 15:09

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


I've been running non-portal sites for friends the past several years, and I selected XOOPS because I could easily create my own modules and provide an Admin back end they could use without any programming expertise themselves. It was pretty good when I started, but the improvements provided with the ThAdmin module are fantastic!!!

I've made some additions there that now allow me to plug the tabs into my own module admin pages and my success there has encouraged me to try again to put in some more specific user group permissions, both for preference categories in my modules and for additional module based group permissions.

I've downloaded and researched permissions handling in XOOPS 2.3 but I don't see anything new in this area. So, here are my questions :

1) Is anyone already working on extending the permissions management, either in XOOPS 2.x or in XOOPS 3.0, and if so who?

2) Is there a tarball for XOOPS 3 somewhere that I can download for research, or is it only available through SVN, and if so where is the connection information?

I'd like to talk with anyone else working in this area before I go off and hack it in myself. Maybe we can share work/ideas.

Thanks.




TopTop
« 1 (2) 3 4 5 ... 7 »



Login

Who's Online

93 user(s) are online (65 user(s) are browsing Support Forums)


Members: 0


Guests: 93


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