|
|
|
|
|
|
| Re: virtual hosts support [message #28226 is a reply to message #5238] |
Fri, 14 October 2005 07:15   |
Anonymous
|
|
|
|
Ok, well, I'm making darn good progress on virtual sites. Cleaned up a fair bit of the icon admin code to make it more conistent between all the different admin options (OK, so I've only looked at mime types and forum icons to start). I have a workable plan in place that allows me to upload icons to the virtual site images directories, yet still be able to select (but not change) the standard system images. Involves a we bit of trickery calling a new script called 'image.php' to display the custom images. Things are looking good.
Now for the bad. What is up with the different image storage formats?? Smiley icons have an 'icon_' prefix, Message icons have none. Mime icons store just the file base name in the table, requiring templates to fill in the image path where as, forum icons store the whole (relative) image path in the table. Forum icons work great with my scheme. Just substitute the new path for the custom images and things are flying. Mime icons on the other hand are a horrible mess. I'm going to have to modify themes and templates and who knows what to dynamically subsitute either the straight standard path or the funky custom path. Is there a logical reason for this? Is there a big picture plan to converge the icon image handling into a single unified format?
Please tell me Mime icons are the exception to the rule and the other Icons work like Forum icons (full relative paths)
|
|
|
|
| Re: virtual hosts support [message #28241 is a reply to message #28226] |
Fri, 14 October 2005 13:57 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
The icon prefix is just a chance occurance, icons do not need to have this prefix, if you upload your own they'll have the original name.
There are no plans to change the image handling process at this time.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28251 is a reply to message #28241] |
Fri, 14 October 2005 16:10 |
ruzam
Messages: 44
Registered: July 2005
Karma: 0
|
Member |
|
|
Hmmm... You have a knack for repeating code 
Ok, now I know you have an aversion virtual hosts support, but bare with me:
Take a close look at icons_adm.inc (skip over the virtual hosting specific bits) and admiconsel.php. These two (one new, one re-write) make for a single unified source of code to handle icons. Greatly simplifies the icon admin mamagement, and totally eliminates admavatarsel.php, admmimesel.php and admsmileyssel.php (or at least it could). I've patched admforum.php and admmime.php to use it so far. The mime patch looks pretty much exactly the same as it did before. The forum patch adds an icon upload section (as it shoud) to the forum editor. As it is in your existing code, you're doing the same thing over and over again. Sometimes the page says it will accept (.gif, *.jpg, *.jpeg, *.png), sometimes the page says it will accept (.gif, *.jpg, *.png), even though it does accept *.jpeg. That's what happens when you duplicate code 
I've eliminated the duplication. All Icons are treated equal, the interface is consitent to the user, the code is simplified. If a future icon type pops into existence, adding it to FUD will be a breaze. In fact, now the code can be tweaked to allow an external URL anywhere an icon can be displayed. That's some awesome flexibility.
BUT, forum icons work out of the box this way. MIME icons do not (and I suspect I'm going to find the same problem with smileys). I can probably fudge a whole bunch of code to maintain compatibility with existing FUD data, but that's going to create a future upgrade mess, or I could break with existing icon storage method, and start clean with a simple common image storage. I'm going to have to tweak the templates for MIME icons either way.
If you don't feel a unified icon management/presentation is a good thing, then I guess my only option is to branch and forget the backward compatibility. If you think common icon code is a good thing, then I'll keep hacking along with compatiblility in mind.
|
|
|
|
|
|
| Re: virtual hosts support [message #28278 is a reply to message #28256] |
Sat, 15 October 2005 17:34 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
I don't exactly see the problem with mime images, like all fud images it uses relative paths images/[dir]/image_file. Mime images are stored in a database for a reason, that being is that they are associated with mime types that need to be referenced somehow. Same is true for smileys/emoticons that need to be referenced to one or more codes.
As far as icons for forums and message those do not need any references and therefor are simply kept as files inside a directory.
As far as unifying code, that is indeed a good idea, although your approach is far more complex then it needs to be. I'll try to come up with my own patch in the next day or two.
FUDforum Core Developer
|
|
|
|
|
|
|
|
|
|
|
|
| Re: virtual hosts support [message #28308 is a reply to message #28299] |
Mon, 17 October 2005 14:39 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Let me explain the logic with avatars.
As you know in FUDforum there are 2 type of avatars, built-in and user-uploaded, consequently there are 2 avatar storage directories. Rather then waste cpu time during page rendering to determine where the avatar is actually found the entire <img src=""> tag is stored in the user's record so it can be displayed to screen without any further processing. Since we already strore the image tag, we also speed up avatar rendering speed by storing the avatars dimensions.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28309 is a reply to message #28296] |
Mon, 17 October 2005 14:43 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
The image paths uses are relative, not full paths so for each (sub)domain they would point at different location. Bottom line is that each site should have its own WWW_ROOT dir in a vhost config. You can cheat and use hardlinks to share some data, but you cannot escape this need.
Why not?
Well, you need different theme dir, so each site can customize the look and feel. You need a different built-in/user supplied avatar dir so each forum can have it's own set of built-in avatars and avoid conflicts with user supplied ones. Same would be true for forum icons, mime icons and message icons.
Aside from that not much is left in WWW_ROOT, so it should not be shared.
FUDforum Core Developer
|
|
|
|
|
|
| Re: virtual hosts support [message #28318 is a reply to message #28317] |
Mon, 17 October 2005 20:03 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
|
|
Actually you can write a mod_rewrite rule based on the hostname, hack you can do it with a faster mod_alias even. If you don't believe that is the case I suggest you read the documentation for those 2 Apache extensions.
FUDforum is designed for flexibility in mind, if you want to customize just the headers that fine, if you want to change the completely look as suprisingly enough people have done it can do that too.
Your idea of one install shared by many as far as you've described is not practical, since it goes contrary to flexebility principles offered by the software.
As far as maintaining many forums, upgrading is as trivial as making a cronjob run the upgrade script on as many forums as you like...
FUDforum Core Developer
|
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]