Jump to content
dev osCommerce
Forum
  • Checkout
  • Login
  • Contact Us
  • Get in touch

osCommerce

The e-commerce.

New Demo
Our Partners

squeekit

Archived
 View Profile  See their activity

  • Posts

    228

  • Joined

  • Last visited

 Content Type 

Posts posted by squeekit

    Information Box Bloat

    in Core Development (Archive)

    Posted · Edited by squeekit

    RL2000,

    thank you...

    thank you very much...

    "display:block;" is an excellent point...

     

    the idea i presented where a classed span is used instead of a list, the "display:block;" only presents two problems, while it still renders very nicely...

     

    problem one: every "<br />" would have to be removed....

    	  $this->_content = '<span class="infolinks">
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</span>';

    the CSS then could be...

    .infolinks a {
 display: block;
 background: #f4f6f8;
 padding: 0px 4px 1px 4px;
 margin: 1px;
 border: 1px solid #bbc3d3;
}

.infolinks a:hover {
 display: block;
 background: #ffffff;
 color: #2266cb;
 text-decoration: none;
}

    this produces a very nice effect - where the entire block becomes a link, rather than just the text.

     

    problem two: however, the removal of "<br />" from the html means that if someone who disabled the CSS or replaced it with their own custom CSS views the page it would cause a loss of this area's structure (links would appear all on one line, and wrap) - this is not really an issue if the fact that by default ms3's entire page structure is lost if viewed under circumstances where the client disables the page's association with the CSS (as i stated before, such is the practice for accessibility reasons) - :) - so in this case yes, having these links in list makes sense, but all that sense is lost when considering the generated page in its entirety...

     

    and so it seems that in this case the span is not such a bad idea (i perfer the "display:block;" effect better in the above example than when used in conjuction with a list) - also "display:block;" is a slightly advanced notion and i would think someone who is familar with it and wants to use it would know how to find and edit out those "<br />" - more chance of that than a novice trying to figure out the list format of those links...

     

    ..............................................................................

     

    don't get me wrong, i love CSS and use it to its max -- but, a balance must be established...

    fact is i moved more heavy into advanced CSS to replace what i use to do with javascript when blocking script became popular -- and so now you know (or can figure out) why i love php :D

     

     

    the info in this post is all for fun -- RL2000, you put me in a good mood - thank you for your consideration :)

    Information Box Bloat

    in Core Development (Archive)

    Posted · Edited by squeekit

    the bottom line...

     

    this is not a BIG problem - but it is a problem - a problem in the direction of the fake borders around the info boxes of ms2, where the "border" is actually a containing table...

     

    in ms3 i am not bothered with the border of all the "boxContents" actually being made with "boxGroup" - for this only adds flexibility...

     

    - i'm mostly bothered with it being an ordered list - that's just absured

     

    - i'm bothered that the code jumps out of html just to jump back into html - that is outstanding unnessicary

     

    - i'm also bothered that the links are in a list - particularly since the list format is doing nothing - this is in the direction of what i mentioned about "fake borders" in ms2, because it throws an added loop to the coders - it's just one more thing that someone has to figure out >>> and it does nothing!

     

    - but above all, i am bothered that i am taking the time to share and explain my findings while little to nothing is explained to me - at least if i take the effort to try to help, i would hope someone would take the effort to consider what i share or at least to educate me...

     

     

     

     

    ---- footnote to previous post ----------------------------

     

    <span class="infoboxlinks">

    ...

    </span>

     

    where "..." would be all links so one span surrounds all links....

    Information Box Bloat

    in Core Development (Archive)

    Posted

    ok ok - i'll explainn the CSS stuff a little more...

     

    IF the list format is important to preserve (for reasons i do not understand yet) then beyond it should be "UL" perhaps it should have a class instead of inline style - like:

     

    <ul class="infoboxlinks">

     

    then you can have tons of fun on the CSS...

     

    but if you merely desire to target these links via CSS, then perhaps they should be nested within something like:

     

    <span class="infoboxlinks">

    ...

    </span>

     

    whatever method is used should:

    - be easy to target via CSS

    - should not render structually different when dissassiated with CSS

     

    etc. etc.

    Information Box Bloat

    in Core Development (Archive)

    Posted

    yes - in a way it looks like i am over reacting - i suppose that is in part because i'm still slightly overwhelmed by the inferior generated html (and inferior CSS) in ms2.2 - i so very strongly do not want to see anything like that again in ms3's final release...

     

    with that being said...

     

    it seems to me the list format is doing nothing and can only cause confusion in the long run...

     

     

    --------------------------------------------------------

    First off, codewise is much easier on the eyses the way it is now...
    there is no difference in the way the page appears in the browser between the example i gave and the original - so you must be speaking solely "codewise" - and i can not help but feel you didn't even look at my alternative solution...

     

    as it is now:

    	  $this->_content = '<ol style="list-style: none; margin: 0; padding: 0;">' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li>' .
					'</ol>';

    a suggested alternative:

    	  $this->_content = '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap'));

    codewise, you can see not only is what i offer easier on the eyes (i should know, as i've stated i am visually impaired, and so code being easy on the eyes is very important to me) - but, it is also easier on the brain...

     

    [ also note: the example above is the one i supplied to create 'new lines' and such alternatively could be done with "\n" if desired ]

     

    FYI - as far as the resulting generated html, my alternative is much easier on the eyes...

    as is now...

      <div class="boxContents"><ol style="list-style: none; margin: 0; padding: 0;">  <li><a href="info.php?shipping&sid=xxxxxxxxxxxx">Shipping and Returns</a></li>  <li><a href="info.php?privacy&sid=xxxxxxxxxxxx">Privacy Notice</a></li>  <li><a href="info.php?conditions&sid=xxxxxxxxxxxx">Conditions of Use</a></li>  <li><a href="info.php?contact&sid=xxxxxxxxxxxx">Contact Us</a></li>  <li><a href="info.php?sitemap&sid=xxxxxxxxxxxx">Sitemap</a></li></ol></div>

    alternatively...

      <div class="boxContents">
					<a href="info.php?shipping&sid=xxxxxxxxxxxx">Shipping and Returns</a><br />
					<a href="info.php?privacy&sid=xxxxxxxxxxxx">Privacy Notice</a><br />
					<a href="info.php?conditions&sid=xxxxxxxxxxxx">Conditions of Use</a><br />
					<a href="info.php?contact&sid=xxxxxxxxxxxx">Contact Us</a><br />
					<a href="info.php?sitemap&sid=xxxxxxxxxxxx">Sitemap</a></div>

     

    IF (and that is a big "IF") - IF there really is a good reason why this is in a list format that has not yet been clearly explained to me, then at the least there are still two bogus things about this particular area:

     

    1 - these links should be in an UNordered list and NOT in an ordered list (as they are now)

    ------ "UL" should be used instead of "OL"

     

    2 - the code should NOT jump out of html only to jump right back into html

    ------ the > ' . ' < should be removed between the "</LI>" and "<LI>"

     

     

    so at the least the code should be as follows...

    	  $this->_content = '<ul style="list-style: none; margin: 0; padding: 0;">  <li>' . 
					osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li>  <li>' .
					osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li>  <li>' .
					osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li>  <li>' .
					osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li>  <li>' .
					osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li></ul>';

     

     

    --------------------------------------------------------

    secondly, having it in a list makes life fun giving more options CSS wise.

    It is how such interacts with the CSS that is one of my main concerns...

     

    being that no class is declared for the list and the style is set inline means the way to access it's attributes via CSS currently would be:

     

    ol {

     

    however, the above means all ordered list would receive such style and such is very undesired...

    the only way to target the list we speak of, and only this list, via CSS would be:

     

    boxContents ol {

     

    and still with that, one would have to wrestle with the inline style...

    basically, as it is now, a coder has to hunt down the page with this code to edit its inline style.

     

    BUT - even more important...

    the way ms3 currently handles its CSS (by default) could mean big trouble, especially considering Harald's reply above...

    Accessibility reasons.

     

    being that "Accessibility" refers to making aspects of computing accessible to physically challenged, particularly the visually impaired, we should consider a common practrice of visually impaired web clients is to substitute their own stylesheets > replacing the stylesheet the page is associated to with their own custom stylesheet. if you look at the pages ms3 generates without its default stylesheet you notice they turn into chaos - losing most all of their structural logic.

     

    the CSS should not be so relied upon - the pages should stand on their own without the CSS

     

    i could go on and on - but instead i'll conclude with....

     

     

    --------------------------------------------------------

    My question to you is: Why is this a problem?

     

    this is a problem mainly for reasons i've stated (yes there's more), but basically i really like the ms3 version and am only trying to help - my criticism is my compliment - in a way, i'm saying "hey, this is great, it's worth making better by doing this or that" - to me that is more help than just saying "hey, this is great"

     

    for ms2 i had to fix its CSS, its generated html, and its PHP -- i am more than glad to help with ms3 -- i've yet much i can share - however, if in my next few suggestions or questions i find they are met with the same answers that explain little to nothing and replies that indicate a lack of consideration of info i offer then i will have no choice but to stop offering help -- as i stated i am visually impaired and so typing info that explains each and every aspect of topics i raise is out of the question, considering how long it takes me to type i can not continue like i have here and replies should be met with much more consideration - i mean heck, by monday i could improve the current ms3 Alpha 3 by 50% at least, if i were so inclined and not share (i know, i looked into it) -- however, as a big thankyou to dev team, i want to share my findings - i know this is a small issue here but if the lack of communication, explainations, and consideration continues i have no choice but to not share...

     

    so in a way this topic is like a test run...

    and that is why i'm putting a little extra effort into all this.

     

    at the least i am only looking for satisfactory answers and have yet to receive any...

    Information Box Bloat

    in Core Development (Archive)

    Posted

    for text readers????

     

    i'm not familiar with those...

     

    you want a "voice" to read the links as

     

    "One, Shipping and Returns.

    Two, Privacy Notice

    Three, Conditions of Use

    ...."

     

    is that how it would work?????

    i don't know, because i'm only visually impaired - and not blind - so i only enlarge text - i don't use 'page readers'

     

    but still -- IF that is how a page reader works i think the numbers of if "read" would be confusing -- i am familar with 'books on tape' and so i know how such sounds --- i think it would be clearer without 'numbering'...

     

    i don't know - as i said i still need some education on this matter :)

    Information Box Bloat

    in Core Development (Archive)

    Posted · Edited by squeekit

    Accessibility reasons.

    sorry i do not fully understand....

     

    to me accessibility refers to things such as font size (making pages accessible to visually impared - as i am) and i do not see how pulling these links out of a list, that i still don't see what it does, inhibits any accessibilty...

     

    even if you meant to say "compatibility" (instead of "accessibility") i still do not see how the list format increases compatibility...

     

    maybe i don't see how because as i stated, i am visually impared ;)

     

    here's the thing - i stay on these seemingly almost meaningless topics till they make sense to me, particularly after seeing all the nonesense in ms2.2's generated html and the vast amount of headaches it's caused the users - so the way i see it, the more osc v3's generated html strays from being straight forward, simple, and efficient, the more the support forum is gonna get cluttered with confusion...

     

    if you would be so kind (or someone) to explain in more detail why the ordered list that does nothing is needed...

    osc_products_images_groups Table

    in Core Development (Archive)

    Posted · Edited by squeekit

    they store the specs for how to size a single image to create different images of different proportions for display in different areas of the osc...

     

    i personally feel this is a big plus for the osc - it use to be (ms2.2) that smaller images being displayed on the osc pages weren't really smaller at all - but rather they were all big images just being displayed at smaller sizes - this really ate up bandwidth (and page load time)

     

    now that osc is going to actually resize images for display means a lot of bandwidth will be saved (and page load times too) :D

     

    kudos dev team...

     

    side note to dev team (mentioned elsewhere too) > PLEASE use php GD to process images (or a choice to use php GD instead of image magick).............

    Issues after install

    in Core Development (Archive)

    Posted · Edited by squeekit

    my 2 cents...

     

    i strongly feel that setting up OSC to rely on Image Magick should totally be dropped!

     

    and instead use the php native GD for image processing...

     

    please educate me as to any reasons why this could not be done

     

    .......... perhaps if there be any real issue..........

    a toggle like switch if there be any desire to use this (image magick) or that (php GD)?

    Information Box Bloat

    in Core Development (Archive)

    Posted

    i mean heck, if you want the generated html to have distinctive lines for each link you can easiely:

    	  $this->_content = '
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br />
					' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap'));

    Information Box Bloat

    in Core Development (Archive)

    Posted · Edited by squeekit

    towards the end of catalog/includes/modules/boxes/information.php why are the links in a styled ordered list that does nothing?

    	  $this->_content = '<ol style="list-style: none; margin: 0; padding: 0;">' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li>' .
					'  <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li>' .
					'</ol>';

    why is the code breaking out of the html only to turn around to re-enter it?

    '</li>' .

    ' <li>'

    why not:

    '</li>

    <li>'

     

     

    BUT even more important, WHY are these links in an ordered list that does nothing???

     

    WHY not make it simple? 

    	  $this->_content = osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'),
$osC_Language->get('box_information_shipping')) . '<br>' . 
					osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br>' . 
					osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br>' . 
					osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br>' . 
					osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap'));

    eventually you guys are either gonna hate me or love me - cause i'm gonna be bugging you about possible refinements ;)

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    I would test it but I don't have the luxury of crashing the site as I am supposed to be finishing this site up asap for the owner.

    I hate to say it but in all honesty, being that you're under the gun (so to speak), I would suggest not playing with this contrib - check out this thread - check out the recuring issues and how many folks got these problems - check out how much time it takes to resolve such issues - and how many never get them resolved - I really don't want to hit this wonderful offering this hard - but at the same time I want to help you the best I can (given my perspective and expirience)..

     

    if you need something like this - perhaps you could get away with a combination of other contribs - like mo pics / on the fly images / watermarking (if needed) - chances are you could get three contribs installed and up within a small percentage of the time it take to get Image Magic woking properly...

     

    sorry :(

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    Vines,

    glad to see you're still here - i'm planning in a week or so to start a new thread concerning the dev of the 'Images & Media' beta contrib - even though i'll not be getting to making it till late this year or early next, i think a discusion of desired features and php intergration, etc. would prove beneficial - would you like me to send you a private message informing of when/where i start such thread or do you think i should merely announce it here in this thread?

    Yes, please. I will be very interested, especially in media (video) capabilities. Look forward to it. I can't offer much by way of php skill, but I can definitely add some stuff related to media.

    yup - you got me goin on this topic - thanks - i announced the plan for the dream at dev of Media Monster v0.0 Beta - hopefully the beta contrib will be finished by spring and refined to the point that within a years time nobody will have to stumble their way along with Image Magic...

    dev of Media Monster v0.0 Beta

    in General Add-Ons Support

    Posted · Edited by squeekit

    [ I thought the Contribution Development area of this forum would be the place to post the following but its guidelines state its only for existing contribs - and the following is merely for discussion and planning of a contrib purposal ]

     

     

    ________dev of Media Monster v0.0 Beta________

     

    This thread serves as the OSC home for the discussion and development of an extensive contrib that covers inclusion of a vast array of media types - from simple images such as *.jpg to video and sound files such as *.mov and *.wav - (etc.). Beyond mere integration into OSC of different media types its planned to incorporate a wide verity of functionality as well.

     

    As of the current date such is only a dream and I do not foresee completion of v1 Beta till spring 2007 - considering, however, the projected size of such an undertaking, I feel this planning stage is important.

     

    Also considering the size of the projected contrib itself when completed I will be unable to make such available through the conventional contrib area (given the size restrictions they have there) - and so I will make it available through one of my personal sites.

     

    I will also set up a forum at such site for support and dev discussion - I mean imagine all the different aspects of this and how difficult it would be to keep track of it all here in these forums.

     

    I should have the OSC Media Monster contrib area (including a designated forum) of a site set up in about two weeks time - I will announce the creation Media Monster's site here in this thread...

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    -- all sidenotes --

     

    pixclinic,

    wow! super list of mods -- thank you much for taking the time to list such - i actually found some in your list that i was on the verge to start searching for - the great thing is seeing them in your list i know that such are 'tested' and work! :thumbsup:

     

    sidesidenote -- lol - believing that Elazar question pertains to css i did not want to spoon feed him/her the info because the more one learns about css the better they are for it -- lol --

     

     

     

    Vines,

    glad to see you're still here - i'm planning in a week or so to start a new thread concerning the dev of the 'Images & Media' beta contrib - even though i'll not be getting to making it till late this year or early next, i think a discusion of desired features and php intergration, etc. would prove beneficial - would you like me to send you a private message informing of when/where i start such thread or do you think i should merely announce it here in this thread?

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    I am only interested in how far could imagemagic go to protect a copyrighted image.
    i agree with pixclinic's statement "I do not believe in image full protection :-)" - i have had many clients ask me about just this - i always talk them into avoiding such and explain that a site design that intergrates images with non-invasive watermarks that incorperates the site's domain name is actualy like free advertising if such images get "gleaned" - i go on to explain all that's involved in the protection of images while pointing out that doing such not only isn't worth the effort but also reduce the much desired 'word of mouth' advertising (which is always 100% free).

     

    so with that being said, i have had a great interest in this too - for mere curiousity's sake...

     

    as far as your question > beyond the watermark, it does not seem to me that imagemagic adds any other means of "image security"

     

    At A Glance / Some Considerations (some random thoughts) ---

     

    last thing first (in theory stage):

    i have yet to explore this but since the final base method of gleaning images would involve a simple screenshot then i would imagine that such can be avoided by actually using single framed (or very short / non moving) video - embedding of certain video formats will display it's image on the page, but will not appear in screenshots --- [ this makes me wonder about the use of a custom DTD > perhaps that can be made to get actual images (jpg, png, etc) not to appear in screenshots like video ]

     

    most overlooked:

    i find that even when sites go to great efforts to 'secure' their images they most often overlook the "Temporary Internet Folder" or cache - for that matter - even 'hotlinking' gets over looked - but the inclusion of simple meta tags that erase the page from a user's computer's "memory" the instant it finishes loading can address this issue - as well, hotlinking can be easily addressed too...

     

    page linking:

    (possibly through 'oncontextmenu>>disable' etc.) even if a page's source is rendered inaccessible (sometimes frames can help do this) a user can still make for themself's a custom html that links to a page with "desired image" and then use "save target as" on the page they made and save the source to their computer for source inspection - so in a sense, being that OSC is php you have a jump start to avoid this issue...

     

    the fact is server side scripting (such as php) might be the best way to protect images (other than that old simple screenshot method) - an extreme example would/could be that the php generated html only uses clear gifs, but the php reads the page and image local, etc to place desired image behind the clear gif using the php which the user will never see via css 'background' or layers perhaps - consider even a css can be dynamic.

     

    Anyhow:

    the list of considerations goes on and on and on (i'm only getting started) - but i believe it's possible to secure images near 100% - but undesired, for once again, doing such may possibly only cause disatisfaction for visitors - you might want to consider a form of "samples" instead of intergration of "important images"...

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    Vines and baker, thanks and thanks...

     

    baker - i had not known the post you spoke of had been so relatively recent - great to note it - i'll check it out first chance --

     

    Vines - Oh yeah - you got me going now :) givin' my schedule i suspect i'll be finished the beta version late this year or early next -- i might even make an installer to automate it's installation - i'm all about being user freindly -- of course such would perform checks and also have a manul install option - my thinking is per haps adding a whole category to the admin > "Images & Media" > hehe - told you, you got me goin - hopfully my schedule will clear up so i can start in on it soon - i'll let you know...

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    (please excuse my recent ramblings)

    Vine,

    the whole point of open source was that anyone can modify or change the base code.
    you are so very right and this point pretty much might leed me to disregard tom's attempt to monopolize and cash in on his contrib (cont help but wonder how much he donates to other contrbutors or osc itself) - however, i'll probably strike out with my own contrib merely because some of the things i desire are indeed fundumentally different from image magic - such as the ability to switch from "on demand" resizing during page request to resizing during upload (with added ability to "pre" resize images already uploaded) - i just don't like the "on demand" resizing -- and also to intergrate many other image features like a 'mor pics that's more sensative to screen resolution, etc. (my introduction into php was with a php image gallery) - i'm just stuned how osc handles images by default (rather nasty) - to cater to those with broadband at this time i can't help but feel is a big mistake - for osc by default to merely create its thumbnails via image attributes is a big minus i feel - etc.....

    Support thread for the Image Magic contribution

    in General Add-Ons Support

    Posted

    Vines,

     

    here's an odd idea for a workaround...

     

    SMALL_IMAGE_WIDTH and SMALL_IMAGE_HEIGHT are both stored in the database -- however you can bypass them or merely use them as is and apply a different method to retrive width and height for other desired dimensions...

     

    note how and where BOX_WIDTH is stored (BOX_WIDTH is used for the side boxes of course) - in /includes/application_top.php: 

    // customization for the design layout
 define('BOX_WIDTH', 140); // how wide the boxes should be in pixels (default: 125)

    i actually added a new definition here so i could have different sized boxes on the left: 

    // edited customization for the design layout - column left
 define('BOX_WIDTH_LEFT', 180); // how wide the boxes on the left should be in pixels

    then i performed a serach on all the files in my catalog and changed 'BOX_WIDTH' to 'BOX_WIDTH_LEFT' where applicatable...

     

    this means that there would be no need to modify the database to add extra image sizes you speak of - instead you could ...........

     

    nevermind (ignore above) here's the trouble...

     

    in imagemagic.php:

    // Get the type of thumbnail we are dealing with
if ( $_GET['w']== SMALL_IMAGE_WIDTH || $_GET['h'] == SMALL_IMAGE_HEIGHT) $thumbnail_size=1;
elseif ($_GET['w'] == HEADING_IMAGE_WIDTH || $_GET['h'] == HEADING_IMAGE_HEIGHT) $thumbnail_size=2;
elseif ($_GET['w'] == SUBCATEGORY_IMAGE_WIDTH || $_GET['h'] == SUBCATEGORY_IMAGE_HEIGHT) $thumbnail_size=3;

if ($_GET['page'] == "prod_info") {
  $thumbnail_size=4;
  $page_prefix = $page ."prod_info_";
}
if ($_GET['page'] == "popup") {
  $thumbnail_size=5;
  $page_prefix = $page ."prod_info_";
}

    then $thumbnail_size gets processed in the code that follows - note how the latter "if statements" change the value of $thumbnail_size -- such as if $_GET['w'] equals SMALL_IMAGE_WIDTH then $thumbnail_size equals the value of 1 --- but later if $_GET['page'] equals prod_info the value of $thumbnail_size gets changed to 4 tossing out the previous value of 1 that indicated SMALL_IMAGE_WIDTH...

     

    let me look into this....

×
×
  • Create New...