xoops forums

Forum Index


Board index » All Posts (geekwright)




geekwright

Quite a regular
Posted on: Today 16:15
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#1

Re: Protector and Bad Ips

Ending with a dot should ban everything that matches up to the dot, i.e. 216.244.66. will ban 216.244.66.1, 216.244.66.2, 216.244.66.3, etc.

I've tested that on 2.5.7 and 2.5.9, and both are working as expected here. (The code changed to support IPV6 between the two versions.)

If there was a problem reading or writing the xoops_lib/modules/protector/config/badips file, you would be able to see that in the protector center.

I'm not sure what is going on in your case, as it works here.


geekwright

Quite a regular
Posted on: 7/23 15:58
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#2

Re: Protector and Bad Ips

The wildcard is supposed to be ending the address with a dot, i.e. 216.244.66.

What XOOPS version are you using?


geekwright

Quite a regular
Posted on: 7/5 18:08
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#3

Re: Xoops Tags and char limit in modules

Quote:

Bleekk wrote:

Does this also prevent that xoops tags will be counted as chars?


Sorry, I misread things.

That works on HTML, not XoopsCode.

You would render first with MyTextSanitizer::xoopsCodeDecode(),
then crop the resulting HTML,
then run through that code to make sure the result is valid.

It isn't perfect, but it should fix the "article destroys the design of the complete website" issue.

Since some modules/configurations might allow HTML, a solution that works with the HTML would be best? We should have a standard function to do that, but we don't yet. Its on my list now.


geekwright

Quite a regular
Posted on: 7/5 15:57
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#4

Re: Xoops Tags and char limit in modules

You can't just cut out a section and expect it to be valid -- you need to work with the DOM.

This sample code takes whatever you cropped, and turns it into valid HTML with all the tags closed:
// $croppedInput is your cropped summary
$doc = new DOMDocument();
$doc->loadHTML($croppedInput);
$docBody $doc->getElementsByTagName('body')->item(0);
$validOutput '';
foreach (
$docBody->childNodes as $childNode) {
    
$validOutput .= $doc->saveHTML($childNode);
}
// $validOutput should now be valid HTML


geekwright

Quite a regular
Posted on: 6/12 20:31
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#5

Re: XOOPS 2.5.9 Notes for Theme Creators

We do accept offers of help

Quote:

aerograf wrote:
Thanks for the answer.
It's a pity that there is not. Will wait.


geekwright

Quite a regular
Posted on: 6/12 20:28
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#6

Re: Default title for the news comments ?

Appears to be a small issue in XoopsModules25x/publisher

Quote:

Bleekk wrote:
Yes you are right.
I hope some of the other developers can help me here


geekwright

Quite a regular
Posted on: 6/12 18:52
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#7

Re: XOOPS 2.5.9 Notes for Theme Creators

Not yet, just this change notification.

Quote:

aerograf wrote:
Is there an updated XOOPS documentation describing the built-in codes and functions?


geekwright

Quite a regular
Posted on: 6/7 15:08
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#8

Re: XOOPS 2.5.9 Notes for Theme Creators

Quote:

Bleekk wrote:
...
Is it possible to create a way so users can add blocks to a module without changing the module itself.
...


That sounds very useful. I'll give that some thought, and see what we could do to implement that.


geekwright

Quite a regular
Posted on: 6/6 18:51
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#9

Re: Language in js

There are several ways you might accomplish this, depending on the exact requirements.

Here is an example from XOOPS 2.5.9, where the image manager code sets up to use the fine-uploader javascript. To do this, we used javascript in a script tag in a Smarty template to initialize the library code, passing in all the required language constants. In the template we can use the language constants as normal -- Smarty will do the substitution in the script code just like it will in HTML.

See the code here, on GitHub:
https://github.com/geekwright/XoopsCor ... tem_imagemanager2.tpl#L52


geekwright

Quite a regular
Posted on: 6/6 16:39
geekwright
geekwright (Show more)
Quite a regular
Posts: 223
Since: 2010/10/15
#10

XOOPS 2.5.9 Notes for Theme Creators

This is a quick overview of some new things that are introduced in XOOPS 2.5.9 that Theme Creators should know about.

Form Renderer

In XOOPS 2.5.9 we have added a XoopsFormRenderer class, and a XoopsFormRendererInterface interface. The XoopsFormRendererInterface defines the final stage of form rendering, allowing the elements to be tailored to better adapt to the theme. XOOPS 2.5.9 ships with two implementations, XoopsFormRendererLegacy which matches the traditional XOOPS form rendering, and XoopsFormRendererBootstrap3 which uses Bootstrap classes to declare the form elements.

By default, XOOPS 2.5.9 will use the Legacy renderer. A theme can choose to use the Bootstrap3 renderer by including a file named theme_autorun.php in its top directory, as is done in the xbootstrap theme, containing the following:

<?php
xoops_load
('XoopsFormRendererBootstrap3');
XoopsFormRenderer::getInstance()->set(new XoopsFormRendererBootstrap3());


New Smarty variables added in XOOPS 2.5.9


$xoops_page contains a condensed version of the current page name. For example, for http://myurl/index.php, $xoops_page would be "index". For http://myurl/modules/profile/edituser.php, $xoops_page would be "profile/edituser".

$xoops_startpage contains the module configured as the start page, or "system" if no module is selected.

A "rendered" key is now set by XoopForm assign() method

Some scripts use the assign() method as an alternative to the display() method. This method assigns the form details to a stem variable named with the form's name. This assignment is done with code that looks like this:

$form->assign($GLOBALS['xoopsTpl']);

This technique has often been done to give the theme more control over the display of the form. It requires the template to loop through the individual form elements, and decide how to display it. This level of control is good if you need it, but can be a nuisance if you just want to position the form inside the page, and you would prefer the system to handle the details.

As of XOOPS 2.5.9, when the program uses the $form->assign() method, an additional stem variable, 'rendered', will be available. Instead of iterating over the 'elements' portion to build the form from pieces, you can simply display 'rendered' to use the system provided rendering:

<{$form_item.rendered}>



Compatibility Breaks

Changes needed to existing profile module override templates

In the profile module, the profile_userinfo.tpl template creates an entire form to provide an activate/deactivate user button. Unfortunately, this form should have a security token. You can see an example of this in the XOOPS 2.5.9 htdocs/modules/profile/templates/profile_userinfo.tpl file at line 54:

<{securityToken}>


Without this change, the button will not work in XOOPS 2.5.9. We try to avoid this kind of compatibility break, but in this case it is necessary.



TopTop
(1) 2 3 4 ... 14 »