tree menu v3.1.1 (development)
Brought to you by:
pratesi
"The PHP Layers Menu System 3.1.1 (development)"
in "tikiwiki-1.8.3"
tree menu shows incorrectly top element if it only one
.|111
..|222
..|333
thus. |111 will be seen as a subelement though from
above anything is not present
.|111
..|222
..|333
.|444
it will be shown correctly
Logged In: YES
user_id=65709
> |111 will be seen as a subelement
subelement of which element?
I have tested on both 3.1.1 and 3.1.3, for both with
.|111
..|222
..|333
and with
.|111
..|222
..|333
.|444
putting such structures in layersmenu-vertical-1.txt and then
loading example-treemenu.php; everything seems OK.
Can you attach at least a screenshot to evidence which problem
you are hitting?
Marco Pratesi
Logged In: YES
user_id=1050761
Full PHPLM from tikiwiki 1.8.3 + screenshot (archive winrar 2.9)
Logged In: YES
user_id=65709
Please avoid unusual (platform dependent?)
archival/compression formats.
Please resubmit the screenshot using .tar, .gz, .bz2,
eventually .zip
Thank you,
Marco Pratesi
Logged In: YES
user_id=1050761
Sorry for a delay.
rar is very popular in russia almost like zip
unrar is free and many ...nix versions exists
http://rarsoft.com/rar_add.htm
Logged In: YES
user_id=1050761
SF has not allowed to upload - the file was too big
Logged In: YES
user_id=1050761
Now Ok
Logged In: YES
user_id=65709
W.r.t. the .rar archiving...
I'm not russian and many sourceforge visitors are not russian.
Furthermore, AFAIK, no Linux distribution bundles any rar
archiver:
as an example, I use Mandrake 10.0, that does not bundle any
rar tool,
and Debian, that provides rar only in the non-free
section[*], because,
contrarily to what you have written, unrar is *not* free /
open source
software, it is only freeware, as it is clearly written in
its license.
AFAIK, also msdos/mswindows does not provide any rar tool.
Anyway, why should I install another archiving tool only to
unpack
an attached archive? And why should I install it on all the
computers
I use? BTW, to use the freeware unrar utility, in general,
I also need
to use a compiler; I usually compile a large amount of
software without
any problem, but, in general, a compiler is not needed to
use and develop
PHP/HTML/JavaScript packages, and the generic sourceforge
visitor
could not even know how to install and use gcc.
Anyway, I am inclined to spend time to study and fix bug
reports,
not to wonder which archiving tool has been used by the bug
reporter.
[*]
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=unrar&searchon=names&subword=1&version=all&release=all
W.r.t. the archive size...
You should refer to a well-defined official release (OK, you
have done
just this) and then attach only what is needed to understand
what
you have added / changed in the official version and what is
needed
to reproduce the problem.
For the future, please, do not attach everything: also
consider that
I usually work on the phplm project when I am at home,
where, thanks
to Telecom Italia, my only Internet connection is a 56k modem...
and I am certainly not the only one that connects to Internet
using a 56k.
W.r.t. the version...
For the future, before submitting a bug report, please check
if the problem is still reproduceable in the latest version:
I often ignore bug reports referred to old releases.
I understand that you have referred to the version bundled
by tikiwiki,
but you should check the newest phplm version anyway; I
suppose that,
if I fix a bug, tikiwiki developers do not release a new
tikiwiki version
just to fix bugs of the bundled phplm version, maybe because
fixed bugs
do not affect the phplm features used by tikiwiki (and this
is the case:
AFAIK, phplm treemenus are not used at all in tikiwiki), or
maybe because
they have already updated the bundled phplm in their CVS but
the fix
will not be available in an official version before the next
planned
official release, and so on.
If the bug (i) has been fixed in phplm, and (ii) has not
been fixed
in tikiwiki, and (iii) *does* affect tikiwiki[*], then maybe
you should
report it to the tikiwiki developers, but there is no reason
to report
it here, as it is not so much sensed to report here an
already fixed bug ;-)
[*] OK, this is not the case, it is just an example.
Marco Pratesi
Logged In: YES
user_id=65709
This bug is fixed in version 3.2beta, released just today.
Please check if the fix is OK for you.
I will close this bug report soon; now I leave it open
because, if I find time, I want to backport this fix
on the 3.0 branch and to release a fixed 3.0.2 version
before closing this report.
Marco Pratesi
Logged In: YES
user_id=65709
I have released just now version 3.0.2,
that fixes this bug also on the current stable branch,
hence I am finally closing this bug report.
Marco Pratesi