Gossamer Forum
Home : Products : Gossamer Links : Discussions :

Subcategory.html

(Page 1 of 2)
> >
Quote Reply
Subcategory.html
I've searched this forum in and out and can't seem to find this answered any where.

I want to use 2 different subcategory.html (subcategory.html and subcategory2.html) template files.

How would I go about doing this?

Please Help!

Thanks,

Blake
Quote Reply
Re: [blakeb] Subcategory.html In reply to
Could you explain why do you want 2 subcategory.html files?

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [blakeb] Subcategory.html In reply to
The short answer is you probably can't without hacking the code as subcategory.html is hard coded.
Quote Reply
Re: [Paul] Subcategory.html In reply to
I want something similar to hotscripts.com, but the root category's are a 3 column listing and the subcategory's are a 1 column listing. Does that mean sense?
Quote Reply
Re: [blakeb] Subcategory.html In reply to
Does anyone know if there's any easy way to do this?
Post deleted by webmaster33 In reply to
Quote Reply
Re: [webmaster33] Subcategory.html In reply to
Yes, but i want my categories on my home page to be 3 columns and my catergories on my category.html to be 1 column and i have a category_sub.html that i want to have a 2 column listing.

Last edited by:

blakeb: Apr 7, 2003, 4:58 PM
Quote Reply
Re: [blakeb] Subcategory.html In reply to
I'm afraid post 3 is still the answer as far as I can tell =(
Quote Reply
Re: [Paul] Subcategory.html In reply to
Well thanks anyway!
Quote Reply
Re: [blakeb] Subcategory.html In reply to
Uh, I wrote a silly thing in my last post, so I deleted.

I think you confused something. If you want to change the column number, you don't have to do anything with subcategory.html.

Well I examined the core code, and it's possible to write a plugin to change the column number (one of my plugins already has something similar feature). The problem is that in both home & category page, the categories are displayed through site_html_print_cat, so you can only change column number together on them (until you don't change this behaviour, using a plugin).

It seems there may be possible to write a global to call instead of <%category%>.
Basically in the global, you should implement a code similar to site_html_print_cat code or use the category_loop to build your own category list.
For home.html page you can set 3 column mode with Admin/Setup/Build Options/ change 'build_category_columns' option from 2 to 3.
And on category.html, you list your categories in 1 column using the suggested global.

Sorry, I'm busy now, so I can't write it for you, but if you start developing it, and you get some problems, me or somebody else will give you some advices & help in your development.

Good luck!

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: Apr 7, 2003, 5:42 PM
Quote Reply
Re: [webmaster33] Subcategory.html In reply to
I'm not the best global writer and have no idea where to start. Would anyone be willing to try and write a global for this. It would make my day. Please

Regards,

Blake
Quote Reply
Re: [blakeb] Subcategory.html In reply to
If you are willing to edit SiteHTML.pm, you might be able to do it this way:

Code:
my $subcat = shift;
my $parent_cat = shift @$subcat;
my $breakpoint = int (($#{$subcat}+1) / $CFG->{build_category_columns}) + ( (($#{$subcat}+1) % $CFG->{build_category_columns}) ? 1 : 0);


When building the home.html page, an empty array is sent for the $parent cat:

Code:


# Will get shifted off in print_cat.
my $root = [{}];
while (my $cat = $sth->fetchrow_hashref) {
push @$root, $cat;
}
my $cat_list = Links::SiteHTML::display ('print_cat', $root);


Whereas in the subcategories, this isn't going to happen, since every subcategory _must_ have a parent.

Code:
$display{category} = Links::SiteHTML::display ('print_cat', $display{category_loop});



So, editing SiteHTML.pm in the print_cat routine, to something like:



Code:
my $subcat = shift;
my $parent_cat = shift @$subcat;
my $breakpoint;
if (exists $parent_cat->{Name}) {
$breakpoint = int (($#{$subcat}+1) / $CFG->{build_category_columns}) + ( (($#{$subcat}+1) % $CFG->{build_category_columns}) ? 1 : 0);
} else {
$breakpoint = int (($#{$subcat}+1) / 3 ) + ( (($#{$subcat}+1) % 3 ) ? 1 : 0);
}


$parent_cat->{Name} would be set for subcategories, but not for the root category,


Where the 3 would give you 3 columns on your home page, but whatever was set in your config on all the other pages.

This should work as long as you are building columns, since $CFG->{build_category_columns} is used as a flag in several places, but the only time it's value is ever checked, is when $breakpoint is set.

This is one change in one routine, and shouldn't "break" your installation if you forget about it during an upgrade.

This is untested, but is a thought.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] Subcategory.html In reply to
I would not recommend editing/hacking of SiteHTML.pm.
You lost upgrade compatibility.

IMO, the problem can be solved by a global, which is used instead <%category%> in category.html.
Sorry, that I don't give exact solution. Maybe later, if I will have more time.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [blakeb] Subcategory.html In reply to
Could you not use a loop....say something like this in home.html;

Code:
<%loop category_loop%>

<%if FatherID != 0%>
# 2 STUFF HERE
<%else%>
# 3 STUFF HERE
<%endif%>

<%endloop%>

Then where the first STUFF HERE bit is, you will need a loop that will go through 3 times, to create a 3 column table. a similar thing will need to be done the second time...but for 2 columns this time.

The reason I think you could get away with checking FatherID, is because it will always be 0 for a root category. In sub-categories there will be a number, i.e. 5,6,7 8, etc.

Hope that makes sense. I havn't tried it...which is why I only posted partial code. I was just playing around with the idea...and thought I would post it Smile

Cheers

Andy (mod)
andy@ultranerds.co.uk
Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!
Quote Reply
Re: [Andy] Subcategory.html In reply to
Andy,

I don't think that would work, because of the need to cut the columns at 1/column_count.

If you want your categories to run left to right/top down, rather than top to bottom/left to right, then your solution would work. I use that sort of thing in laying out the slide pages for the image system.

Left to right also has the advantage of being able to keep "rows" together, rather than having one column work out longer than another. The difference in categories are spread between the rows, rather than all at the end of the column.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [webmaster33] Subcategory.html In reply to
It's a minor change to SiteHTML.pm, and in previous versions of Links, this was the one file that _did_ get hacked -- constantly.

I'm getting near to letting out some beta versions of the software, and _begging_ Alex to add in a "Preserve" feature to the installer, that reads the local config_preserve file, and during an upgrade does *not* overwrite those files, instead installing in the same directory with a _version_number extension.

For the most part, what changes in is the stuff outside the GT:: and library directories, and then an updated interface into them from the "user" or local programs. As sites get more complex, it behooves GT to develop a way to upgrade the libraries, and allow people to integrate the new features as they need to, without killing off their customized site. *NOT* everything can be done through globals, or plugins, or even should be. Sometimes, changing core behaviour is *better*, even though it's not "portable".


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [Andy] Subcategory.html In reply to
Not really, since you have to write a global to change the category column numbers...
So you basically need rewrite of site_html_print_cat code, into a global.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [pugdog] Subcategory.html In reply to
Quote:
It's a minor change to SiteHTML.pm, and in previous versions of Links, this was the one file that _did_ get hacked -- constantly.
I understand this. However doing that for yourself is not the same like suggesting LSQL hacking for other users, especially beginner users.
Having everybody slightly hacking LSQL, will result such confusion, like it happened with Links 2.0, having many incompatible mods for it.
Avoiding suggesting hacks for LSQL, makes upgrades clear, and support easier.
Once somebody hacked LSQL you can't support him easily. He will continue hacking and you lose your support ability.

Quote:
I'm getting near to letting out some beta versions of the software, and _begging_ Alex to add in a "Preserve" feature to the installer, that reads the local config_preserve file, and during an upgrade does *not* overwrite those files, instead installing in the same directory with a _version_number extension.
If a file is upgraded by Alex, and it's not upgraded by the installer, then it may not work together with the new release.
So I see in advance, that Alex will not accept this config_preserve file feature request.

Quote:
allow people to integrate the new features as they need to, without killing off their customized site
Almost all wanted things can be solved through plugins or globals.

I would better want the following improvements in Links SQL:
- improved plugin system (e.g. plugin priority, REPLACE plugin hook type)
- method call support in templates
- GT::SQL improvement to be able to connect to multiple databases
- Config file improvements to be able to refer a variable in the other
(like: <%server_path%>/<%relative_path%> or <%server_URL%/<%CGI_url%>/add.cgi )
- Links::init should be wrapped into a new hook (don't know if it's possible)

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] Subcategory.html In reply to
Quote:
I'm getting near to letting out some beta versions of the software, and _begging_ Alex to add in a "Preserve" feature to the installer, that reads the local config_preserve file, and during an upgrade does *not* overwrite those files, instead installing in the same directory with a _version_number extension.
Quote:
If a file is upgraded by Alex, and it's not upgraded by the installer, then it may not work together with the new release.
So I see in advance, that Alex will not accept this config_preserve file feature request.


Why would you say that? Currently, there are a number of files that are preserved, ignored, or otherwise not modified during an install, and as links gets more complicated, this becomes more important.

Most code is in libraries, which means the "supporting" code, that code outside those libraries, is more site specific.

A number of suggestions have been made over the years on how to allow significant user modifications to the site, without losing them during upgrades, and it's something Alex should seriously consider. The "core" libraries can be updated, without needing to make changes to other scripts. For instance, updating the GT modules to handle updated MySQL conventions would not require changes to the program that simply asks: $db->get() but then goes and does a lot of non-links-like stuff with the results.

The plugins system is good, it's not great, and it's not perfect. Sometimes, rewriting SiteHTML.pm _is_ a better option, even if it has to be done for each upgrade.

If you look at the code in SiteHTML.pm, not much should change, unless something major to links changes. If that happens, those changes should _still_ be backwards compatible in the core code, so the plugins continue to work. So, a modified SiteHTML.pm would still function, without the newer features, similar to how the older template sets function, but without some newer features (I'm having a heck of a time upgrading customized 1.1x templates to 2.12 templates in some _minor_ areas!).

User.pm, is another file that seemed to be where site-specific routines could be placed. I started using Plugins/PUGDOG/User.pm because it wasn't. But, grouping all my library routines into Plugins/PUGDOG is only a part of the solution. I extensively rewrite jump.cgi on every release of Links, to run the postcards site. I have to, since I have special needs (and I didn't do a good job the last time, I was too rushed). I've gone to writing separate scripts, and ignoring the built in scripts on many sites.

Anyway, there is a lot of stuff that could change/improve over time, just like Links 2.0 was a complete rewrite of 1.x. Each program GT/Alex adds to their list, modularizes the SQL engine and core codes even further. Which is good! The big job is going back and getting rid of legacy code, and logic, to make use of it.

Not a high priority, I'm sure, but something that needs to be somewhere on the to-do list.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Last edited by:

Paul: Apr 8, 2003, 1:45 PM
Quote Reply
Re: [pugdog] Subcategory.html In reply to
Uh, could you EDIT & change the <code> to <quote> ? It distorts the thread & makes unreadable. Thx.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] Subcategory.html In reply to
Chill Winston =)

Done.
Quote Reply
Re: [pugdog] LSQL features & upgrade compatibility In reply to
Quote:
Quote:
If a file is upgraded by Alex, and it's not upgraded by the installer, then it may not work together with the new release.
So I see in advance, that Alex will not accept this config_preserve file feature request.
Why would you say that? Currently, there are a number of files that are preserved, ignored, or otherwise not modified during an install, and as links gets more complicated, this becomes more important.
I didn't analize the installer, yet. If you know more about the installer, I have to accept your opinion.

Quote:
A number of suggestions have been made over the years on how to allow significant user modifications to the site, without losing them during upgrades, and it's something Alex should seriously consider. The "core" libraries can be updated, without needing to make changes to other scripts.
Yes, "core" libraries can be updated, without needing to make changes to other scripts, until the inputs & outputs are in the same format, and this behaviour is not changed with the upgrade for none of the functions.

Quote:
Sometimes, rewriting SiteHTML.pm _is_ a better option, even if it has to be done for each upgrade.
I just mentioned, that you are free to modify, but it's not a good idea to suggest/engourage hacking of any core module. Hacking some files _may_ affect plugin working, so may result unnecessary plugin support problems, if hacking some LSQL files will be usual and/or encouraged. I just want to avoid such problems.

Quote:
SiteHTML.pm ... User.pm, is another file that seemed to be, where site-specific routines could be placed
Probably. But in Links 2.0, I always wanted a to have an upgrade-safe solution, to be able to add mods without conflicts, or by managing conflicts. Something that nowadays plugins & plugin installers can do and somewhat handle in Links SQL.
Therefore I don't really like hacks, and I try to avoid them maximally. Thanks to the plugin system, there were really just a few things I was not able to solve with the plugin system.

Anyway. The fact that I would not like to encourage users to hack LinkSQL, would not necessarily mean, that Alex thinks the same. It's possible that Alex will support your idea.

BTW: Could we split this thread & move some posts to a separate thread, under better subject?
(From post #16, except #17 which still belongs to this thread)

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: Apr 8, 2003, 3:13 PM
Quote Reply
Re: [webmaster33] LSQL features & upgrade compatibility In reply to
I'm not saying go willy nilly edit the files, but I did say it was one small change, in one file, that was fairly trivial and insignificant, and far, far easier and less resource intensive than writing a global, plugin, etc.

Then, went on to say that this is not an uncommon need, and some thought should be given to people who do need to edit files.

Plugins are a great way to exend Links, but sometimes modifying it is easier via a code change.

There are so many cool things that can be done, but the mindset of *having* to use a plugin to do it, seems to be slowing the development of these cool things. I'm trying to get around it by creating something that will manage tiny code snippets, and insert them into a larger "plugin" without the need to write a plugin each time.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] LSQL features & upgrade compatibility In reply to
Cool idea with a "tweak-plugin" perhaps?

Klaus

http://www.ameinfo.com
Quote Reply
Re: [klauslovgreen] LSQL features & upgrade compatibility In reply to
Well, my idea is sort of a cross between the current plugin editor and the patch utility, where when a code snippet is posted, a few tags can be added, that describe how it's used, and then it's uploaded/inserted into an existing set of files (or globals.txt).

I'm kind of ignoring the 'hooks' aspect at this point, but a hooks editor is sort of being planned. You can add/delete hooks for routines, and tweak behaviour more specifically. Right now, you need to edit hooks plugin by plugin.

For example, my Days_Old subroutines would be tagged, so when pasted into the upload box the program would take them, see they were a "free standing" routine, and insert them into one of the display.pm files (or create a new one). It would then print a message on how to access the routine ie: "Add <%Plugins::Widgets::Days_Old%> to any template you want to access these variables from." or something similar.

There are some quirks to work out, but this was really a way to create a subroutine manager to keep my code fragments organized. The tagged enhancements would be necessary to make it a general purpose utility for the programming illiterate.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
> >