[pmwiki-users] Image resize scripts like cookbook/minimage
Boris Schwarz
boris.schwarz at inode.at
Wed Nov 8 14:32:50 CST 2006
Hi thanks once more for the help on AuthUser, to Pm Hans and Crisses,
I have another question does one of you have any experiences with image
resizing scripts. I had minimage runnig since months and no problems now i
can around a normal apache installation with php and using the cockbook
scripts results in an error $ErrorResize. Does one of you have a workaround
for automatic resizing of images formats like gif, png jpg or any
experiences with other cockbook scripts the autocamtically resize and create
thumbnails.
Thanks
Boris Schwarz
-----Ursprüngliche Nachricht-----
Von: pmwiki-users-bounces at pmichaud.com
[mailto:pmwiki-users-bounces at pmichaud.com] Im Auftrag von
pmwiki-users-request at pmichaud.com
Gesendet: Mittwoch, 8. November 2006 20:48
An: pmwiki-users at pmichaud.com
Betreff: pmwiki-users Digest, Vol 17, Issue 32
Send pmwiki-users mailing list submissions to
pmwiki-users at pmichaud.com
To subscribe or unsubscribe via the World Wide Web, visit
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
or, via email, send a message with subject or body 'help' to
pmwiki-users-request at pmichaud.com
You can reach the person managing the list at
pmwiki-users-owner at pmichaud.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of pmwiki-users digest..."
Today's Topics:
1. skin override? (Jeff Muday)
2. Re: [pmwiki-devel] ZAP shopping cart question (Crisses)
3. Re: [pmwiki-devel] ZAP shopping cart question (Crisses)
4. Change the home page title (Nico Sica)
5. Re: Change the home page title (Neil Herber (nospam))
6. Re: [pmwiki-devel] ZAP shopping cart question (The Editor)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Nov 2006 13:53:40 -0500
From: "Jeff Muday" <mudayja at wfu.edu>
Subject: [pmwiki-users] skin override?
To: pmwiki-users at pmichaud.com
Message-ID:
<ccdbfa020611081053k249fa67aybaf5893a215bdf37 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I may have missed this in my reading of the documentation, so please excuse
me if I am asking something that is trivial:
Is there a way to mark a particular wiki page to totally drop its skin and
have just a plain-text look? Alternatively, is there a way to have the wiki
page use a different skin than the one defined for the site?
Another alternative: is there a way to make the "Not so simple" skin really
really wide for just the page that has a recipe/script that doesn't fit into
the skin?
reason--
I have a wiki that uses a modified "Not so simple" skin, I installed the
"webadmin" cookbook recipe which just doesn't fit in this skin. The recipe
is quite excellent and has a look that is nice enough to stand alone in a
pure white page.
--
Jeff Muday
Computer Druid, Dept of Biology
Wake Forest University
mudayja at wfu.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
/pipermail/pmwiki-users/attachments/20061108/843d3967/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 8 Nov 2006 14:05:51 -0500
From: Crisses <crisses at kinhost.org>
Subject: Re: [pmwiki-users] [pmwiki-devel] ZAP shopping cart question
To: "The Editor" <editor at fast.st>
Cc: PmWiki Users <pmwiki-users at pmichaud.com>
Message-ID: <AEB4DF04-FDF2-48CE-B916-CC695146998F at kinhost.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Nov 8, 2006, at 1:14 PM, The Editor wrote:
> Thanks Crisses for the input. I hadn't noticed the info you had put
> up on a shopping cart proposal, but read it just now and found it
> quite helpful. It generated some great ideas for me on how to make
> the ZAPcart module far more flexible. I wrote up a response on the
> talk page but thought I would post it here as that page seems to have
> been active for going on two months now, and see if it generates and
> response. Thanks again!
You're rather welcome!
I didn't get very much helpful input on that proposal. I'm not even certain
how feasible it is -- it was a method that occurred to me and woke me up one
morning, and I ran over to a huge whiteboard in my home office and started
scribbling. :)
> Posting to this a bit late, but had a few comments, in relation to ZAP
> and the ZAPcart module...
>
> 1) While I wasn't thinking Mall, I do believe a way could be
> configured for multiple merchants to set up separate shopping carts.
> It would require you to have a configurable Order.Items page (where
> item info is stored), or better yet a configurable Order group which
> would make each store fully independent.
It needs to generate separate carts for each merchant, since the payments
would be separate. Amazon.com is somewhat similar -- when you buy used
books, they generate your order as one, but your card/ payment is charged
separately for each of the merchants. That's where some of the inspiration
comes from.
> 2) Sounds like the proposal you are suggesting is a bit complex, but
> it may be necessary for complex needs. The ZAPcart module is really
> designed for small shops with simple needs. But there may be other
> ways to solve the flexibility needs. Namely:
It is certainly complex. I'll agree with that. But there's more complexity
for the programmer -- on the user end it only gets complex when setting up a
complicated store.
Here I'm selling one product, with 2 size options:
(:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
(:item XyZ name="Product Name" desc="Product description"
pic=http://example.com/products/pic.gif:)
(:pic http://example.com/products/pic2.gif:)
(:options QHI name="Size" select=1:)
(:option 8oz name="Small" default
amt=123.45:)(:optionend:)
(:option 20oz name="Large"
amt=10.50:)(:optionend:)
(:optionsend:)
(:itemend:)
(:cartend:)
"cart" sets basic cart defaults -> a code for the cart (XES1), who the
seller is (XES -- which could tie back to the Profile page I guess), what
method(s) of payment are accepted (PayPal & its email for payment), and that
the default for all of the XES1 cart items is that they're taxable. I could
leave "tax" out and put it into the item instead. Because it's modular, I
can specify the picture for the item, or a picture for each item's size
options. Of course, if I weren't putting in pictures of the item(s), and
the item had no options, it would be pretty simple:
(:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
(:item XyZ name="Product Name" desc="Product description"
pic=http://example.com/products/pic.gif:)(:itemend:)
(:cartend:)
I've considered whether to use explicit open/close tags or a different
method, but until I get even close to proof-of-concept, this is simply a
"concept" for how to set up a store. The store is product-driven, rather
than trying to cram one's products into the available features of the cart.
The only requirement in each item, option, coupon/discount, or cart as given
is that the item have a code.
Then there's issues about how to display something so flexible. I was
considering that in the (:options:) tag I would allow people to specify
whether they want a drop-down, checkbox, radio button, etc.
So my idea has issues. :) I was hoping that people would catch on to the
concept behind it, and help move along the problem-solving phase of the
concept brainstorming.
I've used ZenCart, and it's also complicated, but part of the problem is
that there are SO MANY menus for setting up the store -- it's complicated
for the USER. Much too much back-end administration
complexity. Usable? yes. Better than oscommerce? By a long shot.
But OSCommerce's back-end was easier to administer; ZenCart merged several
oscommerce plug-ins into the core, which complicated the administration.
> 3) The javascript function can be modified by any programmer fairly
> easy to calculate shipping and taxes any way desired. You could also
> specify the javascript file in a SDV (or perhaps in the markup), so
> different checkouts could use different approaches. Defined in a
> local config file.
I personally find this absolutely unacceptable, especially where membership
or downloads may be concerned. If someone is not hand- calculating the
order, people can mess with the functionality of the JavaScript, and perhaps
send through orders with lower prices -- maybe even $0.00 or $0.01. It's
one of the big failings of browser-
scripting. I had put encrypted Buy Now button code in the cookbook.
Someone else came up with a more flexible and easier method that could be
done by any wiki author to create buttons -- and it's a great solution --
but the reason for the encrypted buttons is so people can't change the
prices on the order.
> 4) The format of the ZAPcart order and checkout sections could be
> defined in a separate PmWiki page (like ZAP's email templates), to
> make them quite easy to configure. To allow multiple kinds of forms,
> I could change the markup to allow an optional pagename into the
> zaporder directive. Otherwise the current default would be used. This
> *should be* easy enough to do.
>
> 5) I think, without looking closely, additional parameters could be
> stored for items fairly easy and made accessible to the order and
> checkout sections, and to the javascript functions the same way it is
> currently done. Basically it explodes the item info by pipes--so
> other fields in that array should be just as available as the price
> and name.
pipes is ok too -- I wanted something human-readable, so you might want to
allow spaces around the pipes
> 6) As for options for items, I don't know any *easy* way to do that.
> But without too much trouble, each variations of an item could be
> stored as a separate item, and a special code could be put in the
> zapcart markup that would create a pulldown menu with options. A bit
> of coding but not much.
I'd like to see that. Not every store needs to be as complicated as my
proposal.
Also, if we work with similar mark-ups, if someone wanted to upgrade, it
wouldn't be as hard.
> 7) Things like discounts, coupons, gift certificates, shipping
> options, payment options, would be more complex but could be added
> *perhaps* using ZAP's conditional capabilities and/or replacement
> fields. The javascript would also have to be written to make the
> appropriate changes.
> 8) I suppose a way could be set up for ZAP to handle inventory control
> (in stock or out of stock) but I have no idea how, and would probably
> rather not tackle that within the ZAPcart module. It seems it would
> be for a more industrial strength application with direct tie in's to
> a company's database. Something way out of ZAP's limited scope.
That's out of scope for what I was thinking also -- at least for now. Once
you get into that, you might as well drag a database into it. Once I try to
cram my concept into a database, it becomes much more complicated. That's
one of the nice things about the wiki version -- nearly arbitrary data
nesting.
> I really appreciate the conceptual work you did Crisses, but think
> starting with something very simple and building extensibility into it
> might be a better option. I know the basic ZAP cart system works like
> a charm and it is extremely easy to set up. Making the various parts
> of ZAP more configurable would make that same ease of use available to
> much more diverse applications with minimal editing, and without
> having to reinvent the entire framework.
>
> Any thoughts?
I'm very hesitant about the JavaScript portions. For updating totals on a
page, sure, but for anything critical before payment I would not be happy.
I would think any order needs to be checked before it's sent to the payment
processor.
> Cheers
> Caveman
>
> PS. What did you mean by "What I'm going to need VERY soon are things
> like tying in user access to PayPal subscription services, as an
> example". Don't have a clue how this would work, but I'm interested.
> I wouldn't mind having a section of my site only available to those
> current on their subscriptions. But can't see how PayPal and PmWiki
> can communicate sufficiently to automate this. How were you thinking
> about going about it?
PayPal has a subscription service. I don't fully understand how it works
yet, but they will create recurring payments and send subscription info to
your website (through a specific URL on your site). I would want to tie in
subscriptions to the authentication module I've (re)created. Mine uses
databases, but it should be able to be done without a database. So I would
do this by, for example, having a wiki url divert to a specific recipe
function -- that function accepts the PayPal information and changes the
user's privileges accordingly.
So it's similar to the PayPal Payments Pro, I think -- where you send an
order to PayPal, and PayPal returns verification to your site that the
customer has indeed paid. I've looked at the documentation, and they have
some code samples, but I have to go over it again more thoroughly at some
point.
I'm not interested in pay-only sites, but I had a customer who is.
What I need is like you said: elevated privileges for a price. So someone
pays and is added to a privileged group with additional access to other
features. When their subscription runs out, PayPal renews them or their
access to the privileged group is removed.
I'd love to accept other methods of payment, but services such as PayPal are
very cost effective compared to some credit card merchants. So, one thing
to be careful about in developing these modules is to indeed make them
modular -- separate the payment method/ processor from the code, so that
people can create other plug-ins for other merchant services.
I would be doing this as an add-on for the new AuthUserDBase that has
stand-alone features. It probably comes right after I add the ability for
the module to control groups -- I was able to do it for vBulletin, so I'm
sure I can do database-to-wiki group conversions.
Crisses
------------------------------
Message: 3
Date: Wed, 8 Nov 2006 14:15:21 -0500
From: Crisses <crisses at kinhost.org>
Subject: Re: [pmwiki-users] [pmwiki-devel] ZAP shopping cart question
To: Crisses <crisses at kinhost.org>
Cc: PmWiki Users <pmwiki-users at pmichaud.com>
Message-ID: <7C8C7DA5-47E1-43C1-9808-2C99C0D9839D at kinhost.org>
Content-Type: text/plain; charset="us-ascii"
On Nov 8, 2006, at 2:05 PM, Crisses wrote:
> Of course, if I
> weren't putting in pictures of the item(s), and the item had no
> options, it would be pretty simple:
>
> (:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
> (:item XyZ name="Product Name" desc="Product description"
> pic=http://example.com/products/pic.gif:)(:itemend:)
> (:cartend:)
Get your FREE Product Name here!!
I forgot the price :) insert: "amt=10" :)
Crisses
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
/pipermail/pmwiki-users/attachments/20061108/20aead20/attachment-0001.html
------------------------------
Message: 4
Date: Wed, 08 Nov 2006 20:37:50 +0100
From: Nico Sica <g.sica at polimetrica.org>
Subject: [pmwiki-users] Change the home page title
To: pmwiki-users at pmichaud.com
Message-ID: <4552320E.9050404 at polimetrica.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hello,
When I open my pmwiki I've the home page.
Of course the title is "home page".
I'd like to change it.
Do you know how can I do?
Many thanks.
All the best,
Nick
------------------------------
Message: 5
Date: Wed, 08 Nov 2006 14:47:04 -0500
From: "Neil Herber (nospam)" <nospam at eton.ca>
Subject: Re: [pmwiki-users] Change the home page title
To: Nico Sica <g.sica at polimetrica.org>
Cc: pmwiki-users at pmichaud.com
Message-ID: <45523438.9070201 at eton.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Nico Sica wrote:
> Hello,
> When I open my pmwiki I've the home page.
> Of course the title is "home page".
> I'd like to change it.
> Do you know how can I do?
You can put a title directive on *any* page like this:
(:title This is My New Title:)
--
Neil Herber
Corporate info at http://www.eton.ca/
------------------------------
Message: 6
Date: Wed, 8 Nov 2006 14:47:57 -0500
From: "The Editor" <editor at fast.st>
Subject: Re: [pmwiki-users] [pmwiki-devel] ZAP shopping cart question
To: "PmWiki Users" <pmwiki-users at pmichaud.com>
Message-ID:
<fec7cf150611081147x177b1040n8e59dde4bf2582d3 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 11/8/06, Crisses <crisses at kinhost.org> wrote:
> On Nov 8, 2006, at 1:14 PM, The Editor wrote:
> It needs to generate separate carts for each merchant, since the
> payments would be separate. Amazon.com is somewhat similar -- when
> you buy used books, they generate your order as one, but your card/
> payment is charged separately for each of the merchants. That's
> where some of the inspiration comes from.
Yes this should work just fine. I'll do it for the next release.
> It is certainly complex. I'll agree with that. But there's more
> complexity for the programmer -- on the user end it only gets complex
> when setting up a complicated store.
>
> Here I'm selling one product, with 2 size options:
>
> (:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
> (:item XyZ name="Product Name" desc="Product description"
> pic=http://example.com/products/pic.gif:)
> (:pic http://example.com/products/pic2.gif:)
> (:options QHI name="Size" select=1:)
> (:option 8oz name="Small" default
amt=123.45:)(:optionend:)
> (:option 20oz name="Large"
amt=10.50:)(:optionend:)
> (:optionsend:)
> (:itemend:)
> (:cartend:)
Mine might be as simple as changing (:zapcart itemcode:) to (:zapcart
itemcode|size:)
> > 3) The javascript function can be modified by any programmer fairly
> > easy to calculate shipping and taxes any way desired. You could also
> > specify the javascript file in a SDV (or perhaps in the markup), so
> > different checkouts could use different approaches. Defined in a
> > local config file.
>
> I personally find this absolutely unacceptable, especially where
> membership or downloads may be concerned. If someone is not hand-
> calculating the order, people can mess with the functionality of the
> JavaScript, and perhaps send through orders with lower prices --
> maybe even $0.00 or $0.01. It's one of the big failings of browser-
> scripting.
Are you talking about a security vulnerability or a poor programmer
setting it up wrong? I mean, javascript is not that complicated
though it is a bit weak on math. The way my script works, users
cannot edit the line totals, only the quantity. And it recalculates
onblur so you always have the exact total. I could have php calculate
the total, and may do that first anyway for non Javascript browsers,
but it would be quite limiting
Forget headers should not be a big problem if that's what your
thinking because this uses ZAP's session variables helps to ensure
authenticity. Let me know if I'm missing something. I certainly
don't want something that is risky to use.
Actually, on second thoughts, if the total is changeable you have a
potential that that value could be forged. Which suggests it might be
best to have a preview page, and an actual finalization page. The
first could be edited by javascript. The second would be set in
stone. Would that solve the concern you are addressing? A bit of
trouble perhaps, but probably worth it.
> I'm very hesitant about the JavaScript portions. For updating totals
> on a page, sure, but for anything critical before payment I would not
> be happy. I would think any order needs to be checked before it's
> sent to the payment processor.
See my notes above on the possibility of a preview markup, and a
checkout markup. The disadvantage is, an admin that wanted to modify
the price calculation system would have to do it twice--one in
javascript and one in php, for the two different phases. Not ideal.
But agree that for downloads and access fees, it might be necessary.
> > 6) As for options for items, I don't know any *easy* way to do that.
> > But without too much trouble, each variations of an item could be
> > stored as a separate item, and a special code could be put in the
> > zapcart markup that would create a pulldown menu with options. A bit
> > of coding but not much.
>
> I'd like to see that. Not every store needs to be as complicated as
> my proposal.
I think I can do this much. Will try for the next release...
> Also, if we work with similar mark-ups, if someone wanted to upgrade,
> it wouldn't be as hard.
I think we are probably talking about pretty different approaches.
The ZAPcart's markups are next to nothing. And the item list storage
is just a single page of lines like (:item: name|cost:). So, not too
much I even have available to change.
> > 8) I suppose a way could be set up for ZAP to handle inventory control
> > (in stock or out of stock) but I have no idea how, and would probably
> > rather not tackle that within the ZAPcart module. It seems it would
> > be for a more industrial strength application with direct tie in's to
> > a company's database. Something way out of ZAP's limited scope.
>
> That's out of scope for what I was thinking also -- at least for
> now. Once you get into that, you might as well drag a database into
> it. Once I try to cram my concept into a database, it becomes much
> more complicated. That's one of the nice things about the wiki
> version -- nearly arbitrary data nesting.
Well, I'll stop the wheels from turning on this one then. Though I
might want to find a way for an admin to flag an item as out of stock.
It might be changing that item to (:item: ITEM--OUT OF STOCK|0:)
> PayPal has a subscription service. I don't fully understand how it
> works yet, but they will create recurring payments and send
> subscription info to your website (through a specific URL on your
> site). I would want to tie in subscriptions to the authentication
> module I've (re)created. Mine uses databases, but it should be able
> to be done without a database. So I would do this by, for example,
> having a wiki url divert to a specific recipe function -- that
> function accepts the PayPal information and changes the user's
> privileges accordingly.
>
> So it's similar to the PayPal Payments Pro, I think -- where you send
> an order to PayPal, and PayPal returns verification to your site that
> the customer has indeed paid. I've looked at the documentation, and
> they have some code samples, but I have to go over it again more
> thoroughly at some point.
>
> I'm not interested in pay-only sites, but I had a customer who is.
> What I need is like you said: elevated privileges for a price. So
> someone pays and is added to a privileged group with additional
> access to other features. When their subscription runs out, PayPal
> renews them or their access to the privileged group is removed.
I didn't know about this. I should look into it some more and see if
there's a way to get that url to update zap stuff. It seems using
ZAPget I could get the info from the url, I could construct a zap form
based on that info, with appropriate conditionals, etc. And I've
learned how to trigger a form submission onload by embedding it in a
gif. (How the zapcart works). This could make paypal's notifications
trigger automatic zap forms to enable whatever you wanted.
Keep me posted if you find more info. I would be interested in trying
to set up a snippet for this in zap if you can find out the exact
spec's on what they send you.
> I'd love to accept other methods of payment, but services such as
> PayPal are very cost effective compared to some credit card
> merchants. So, one thing to be careful about in developing these
> modules is to indeed make them modular -- separate the payment method/
> processor from the code, so that people can create other plug-ins for
> other merchant services.
>
> I would be doing this as an add-on for the new AuthUserDBase that has
> stand-alone features. It probably comes right after I add the
> ability for the module to control groups -- I was able to do it for
> vBulletin, so I'm sure I can do database-to-wiki group conversions.
I suppose that could be added to ZAP by making the zappay directive
configurable also in a wiki page. Ahhh, love that PmWiki flexibility
thing!
Cheers,
Caveman
------------------------------
_______________________________________________
pmwiki-users mailing list
pmwiki-users at pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
End of pmwiki-users Digest, Vol 17, Issue 32
********************************************
More information about the pmwiki-users
mailing list