61
zyspec
Re: Adslight 2.2 error after upgrade 2.5.8
  • 2019/4/12 3:02

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@yurdal,

It looks like quite a few corrections have been made in Mamba's fork and he's submitted a pull request to XoopsModules25. Looks like if he can integrate the pull request into the main branch on XoopsModules25 then we can test that version to see how to proceed.



62
zyspec
Re: wgTeams Problem
  • 2019/3/29 22:13

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@heyula,

You might want to make sure that the module uploaded to your server correctly. Specifically check to see if ./class/Helper.php exists.



63
zyspec
Re: Animal pedigree module
  • 2019/3/5 22:54

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


One other thought, looking at the errors. Which text editor are you using? This looks like these could be errors related to loading the links for a WYSIWYG editor.



64
zyspec
Re: Animal pedigree module
  • 2019/3/4 23:46

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@John2021,

The change appears to have fixed the failure you were experiencing:

Quote:

require_once(/modules/pedigree/include/wizard.php): failed to open stream: No such file or directory in file /modules/pedigree/include/CheckoutWizard.php line 2


Can you tell me the page you're on when you get all the warnings? Does this happen when you perform an action (like when you press "Submit") or just when the page loads?



65
zyspec
Re: Animal pedigree module
  • 2019/3/4 16:36

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


Looks to me like the 1st thing to fix is:

In ./pedigree/include.CheckoutWizard.php change line 2 from:
require_once __DIR__ '/wizard.php';

to:
require_once __DIR__ '/ZervWizard.php';



66
zyspec
Re: Animal pedigree module
  • 2019/2/25 16:45

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@John2021

I don't have the module loaded but can you turn on debug in System Preferences and copy the results here? Maybe we can find a quick fix to get you past this error.



67
zyspec
Re: set class for form elements
  • 2018/7/16 16:37

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@goffy,

I apologize for misunderstanding your original request - I think I do now. You are correct, unfortunately neither the XoopsFormRenderLegacy or the XoopsFormRenderBootstrap3 classes render the Form Button Element's class information. It looks like 'renderFormButton' method should be modified similarly to what you've done in both of these classes. The only difference between the Legacy and Bootstrap3 class methods would be the default classes rendered if the getClass() method returns false.

It looks like this is very similar to what has been done already in XOOPS 2.6 so anything written to utilize your proposed change for 2.5.x should behave similarly in 2.6.

There are several other element types which will have the same issue (Radio, Button Tray, Checkbox, etc.) so UNLESS they're all going to be changed I wouldn't recommend this for the 2.5.x core. Having these elements behave differently from each other (ie. you can't count on the behavior) then I don't think there's enough value in XOOPS 2.5.x to make this change. If someone's willing to change it virtually "everywhere" in 2.5.x rendering engines then it would be a valuable addition.

Just my 2 cents.

But yes, I would be a proponent of changing it "everywhere" in 2.5.x if someone has the time to code/test it - I'm just not sure the current core team has the bandwidth to provide us that luxury.

[EDIT]
One short term "hack" is to use the setExtra() method to set the additional class information since the "extra" information is rendered. Using this method would then give you a button with multiple separate 'class' attributes but it might be a better solution than nothing. Most modern browsers will render this as expected. So you would end up with a button rendering that looks something like:
<input type='button' class='btn btn-default' name='myButton'  id='myButton' value='Submit and go to images upload' title='Submit and go to images upload' class='btn-success' />';

While not ideal you could do something similar to this for each HTML element type you use (button, radio, etc).

Just an idea
[/EDIT]



68
zyspec
Re: set class for form elements
  • 2018/7/10 14:56

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@goffy,

If I understand your question you want to use the XoopsForm element classes to instantiate and then render the element, correct?

If so, yes you can do that. You can do something like:
$myRadioElement = new \XoopsFormRadioYN('Is the weather nice today?''ynradio');
echo 
$myRadioElement->render();


This will render a simple Yes/No radio element. Of course you can also "capture" the output in a variable and then display it later if you want too:
$myRadioElement = new \XoopsFormRadioYN('Is the weather nice today?''ynradio');
$radioHTML $myRadioElement->render();
... <
more code here> ...
echo 
$radioHTML;



69
zyspec
Re: Wfdownloads 3.30 Beta-1 for XOOPS 2.5.9 and PHP 5.6+
  • 2018/6/11 0:34

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


Unfortunately it looks like Mamba forgot to rewrite part of the install function in the ./include/oninstall.php file. You might try replacing lines 41-64 (the xoops_module_pre_install_wfdownloads function) with:
function xoops_module_pre_install_wfdownloads(XoopsModule $module)
{
    include 
__DIR__ '/common.php';
    
/** @var XoopsModulesWfdownloadsUtility $utility */
    
$utility = new XoopsModulesWfdownloadsUtility();
    
//check for minimum XOOPS version
    
$xoopsSuccess $utility::checkVerXoops($module);
    
// check for minimum PHP version
    
$phpSuccess   $utility::checkVerPhp($module);
    if (
false !== $xoopsSuccess && false !==  $phpSuccess) {
        
$moduleTables =& $module->getInfo('tables');
        foreach (
$moduleTables as $table) {
            
$GLOBALS['xoopsDB']->queryF('DROP TABLE IF EXISTS ' $GLOBALS['xoopsDB']->prefix($table) . ';');
        }
    }
    return 
$xoopsSuccess && $phpSuccess;
}


That should at least get you past the pre-install check for PHP and XOOPs versions.



70
zyspec
Re: countdown module for XOOPS 2.5.9 ?
  • 2018/6/8 15:21

  • zyspec

  • Module Developer

  • Posts: 1093

  • Since: 2004/9/21


@ultraman147,

You're correct. I apologize, I missed 2 more places that need to be changed.

In the same file (./templates/countdown_index.tpl) around line 26 you will see:
<a href="../index.php?op=edit&amp;id=<{$event.id}>"><{$event.name}></a>

please change it to:
<a href="./index.php?op=edit&amp;id=<{$event.id}>"><{$event.name}></a>


and similarly around line 46 you will see:
<a href="../index.php?op=add"><{$smarty.const._CD_TEXT_ADD_EVENT}></a>

please change to:
<a href="./index.php?op=add"><{$smarty.const._CD_TEXT_ADD_EVENT}></a>


I hope this helps.




TopTop
« 1 ... 4 5 6 (7) 8 9 10 ... 100 »



Login

Username:
Password:

Lost Password? Register now!

Who's Online

113 user(s) are online (28 user(s) are browsing Support Forums)


Members: 0


Guests: 113


more...

Donat-O-Meter

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

Latest GitHub Commits