Leaderboard

A few notes about text bounding boxes which, I hope, will help in precise placement of your text. Suppose I have the text string "The lazy fox" which I want to display using 150pt Vivaldi . My image is 4896 x 3672 and I want the text placed at the bottom right but 250 pixels from the edges of the image. $box = imagettfbbox(150,0,'c:/windows/fonts/vivaldii.ttf','The lazy fox'); gives this array of coordinates of the four corners $box = Array ( [0] => 23 [1] => 55 [2] => 871 [3] => 55 [4] => 871 [5] => -140 [6] => 23 [7] => -140 ) You may wonder why it can't just give a rectangle from (0,0) to (width, height) to make sizing simple, but there is extra information to be extracted from the array Text width = (871 - 23) = 848 Text height = 55 - (-140) = 195 The baseline will be 140px from the top The text is offset 23 px to the right. My text, therefore, will be in a rectangle 848 x 195 positioned 250 px from right and bottom edges. The top left x coord of the rectangle will be (4896 - 250 - 848) = 3798 and top left y coord will be (3672 - 250 - 195) = 3227. However, to land the text precisely into this area we position it on the baseline and at the required x offset, ie (3798 - 23 , 3227 + 140) = (3775, 3367). I use a simple custom function to assist with this process function metrics($font, $fsize, $str) { $box = imagettfbbox($fsize, 0, $font, $str); $ht = abs($box[5] - $box[1]); $wd = abs($box[4] - $box[0]); $base = -$box[5]; $tx = -$box[0]; return [ 'width' => $wd, 'height' => $ht, 'ascent' => $base, 'offsetx' => $tx ]; } $box = metrics ('c:/windows/fonts/vivaldii.ttf', 150, 'The lazy fox'); $box = Array ( [width] => 848 [height] => 195 [ascent] => 140 [offsetx] => -23 )

You obviously don't know any php and furthermore are not willing to open up a book and look anything up. The trim function (mentioned above) is one that removes leading and trailing spaces from a string. That is all. It has nothing to do with a loop or with output. Why are you into something this deep if you don't know anything about php or programming? As a professional programmer I find it ridiculous when people with no knowledge think they can just jump into it and hope someone can hold their hand for the next 2 months teaching them what they should already have tried to learn for themselves. Have fun. It's a learning process that can possibly give you a new set of knowledge that you may find invaluable. But - it takes work. Good bye

Make ticket_number an auto_increment column CREATE TABLE raffle ( name VARCHAR(50) ticket_number INT NOT NULL auto_increment primary key ); INSERT INTO raffle (name) VALUES ('Curly'), ('Curly'), ('Curly'), ('Larry'), ('Larry'), ('Larry'), ('Larry'), ('Larry'), ('Mo'), ('Mo'), ('Mo'), ('Mo'), ('Mo'), ('Mo'); SELECT name, ticket_number FROM raffle; +-------+---------------+ | name | ticket_number | +-------+---------------+ | Curly | 1 | | Curly | 2 | | Curly | 3 | | Larry | 4 | | Larry | 5 | | Larry | 6 | | Larry | 7 | | Larry | 8 | | Mo | 9 | | Mo | 10 | | Mo | 11 | | Mo | 12 | | Mo | 13 | | Mo | 14 | +-------+---------------+

The "check" is actually the result of the animation. Look at the animation itself for where you can change the color.

Note that "$get_the_title()" is not the same as "get_the_title()".

Alternatively, you could just update the line that defines $site_title. That way you're not calling get_the_title() multiple times. Plus, the value should be escaped for inclusion in an HTML attribute. $site_title = esc_attr( get_the_title() ); As for the following, WordPress' the_title() function echos the value be default. I forget what happens when you try to echo something that has already been echoed in WordPress, but that probably lead to the issues you were having.

The braces are required when embedding complex variable names (an array element) inside other things. Without them you would get a syntax error. You could use concatenation (dots) to avoid this but with the braces you can skip the concatenating and just compose one contiguous string here. The thing I wanted you to note was the quotes on the array indices. A Key thing!

echo "<a href='{$row['link']}' target='_blank'>&diams;&nbsp;&nbsp; {$row['title']}</a><br>";

Note that is for the fixed-width fonts that GD supports out of the box. With TTF fonts, character widths vary so calculating the right offset is a bit harder.

@gizmola, Thanks for the thoughts. All of this is definitely a journey, because as I sketch things out (and talk to people) I learn new things and that can change my design. Dealing with the unknown and not knowing how to design things until you successfully design thing is what makes all of this a challenge! I'll take what you and others have said above and try to come up with a design that is flexible, scalable, and that helps me retain customers and make $$$. Thanks.

Hey Saranac, You seem to be conflating a "transaction" which is a database specific term, with a single page application (SPA) or combined form. What you do serverside with that form is up to you. Ease of use, credit card/payment processing and the dangers and cost of fraud are a complicated witches brew of risk/reward calculations. First of all, I don't know what you know or don't know about payment processing, but just because you got a cc authorization doesn't mean you will ever get paid. Worse yet, you could get a chargeback, and if you have enough chargebacks, you might end up having your merchant account closed. Again, maybe you know this or you don't. I don't know what your content is, or whether or not there will be a high amount of fraudulent activity, but every online business has some. So, as to transactions, and to "best practices" for selling digital goods or memberships, these topics are unrelated. At its simplest, a Member in your system, as you stated yourself, is not equivalent to a membership package. Membership packages also have one or more related "entitlements". So no doubt you have a package described in the database somewhere, and when someone successfully subscribes to a package for a year, one would expect a database structure like this: package ---< member_package >-- member where member_package is a table that stores "member_id", "package_id", "from_date", "to_date". What are strategies for dealing with the system. Well one, would be to have the culmination of a successful payment process be the setting of the "from_date" and "to_date". Another strategy might be to also utilize a "status" column with mutually exclusive states like: pending payment active suspended for fraud expired In that case you create the row, and can then use "active" status to drive access (along with from/to). Regardless of the form you use, there is no benefit to wrapping the creation of a member row with the transaction processing. If a member fills out all their details and has payment processing issues, it behooves you to create the membership row and put them into "pending payment" state. This way you can see how many people had issues with payment processing at any particular period of time. That way you can reach out to people who for whatever reason drop out of the payment process. You have contact info to market to them, or entice them with discounts. And there is always the situation where your payment processor was rejecting everything and these are customers you have 100% lost forever without some record that they tried to subscribe. DB transactions are important from a mechanical standpoint and I highly recommend using them, but you can have multiple transactions in your processing ie (membership account + address) THEN (payment processing & activation) and these can be handled separately in your code. Once you have some identity information, it's valuable to continue to carry this along in your session rather than stubbornly demand that the behavior of your system should conform to your ideal "happy path" scenario where a user puts in all their identity information for their membership perfectly, and at the same time gets the payment information entered perfectly and receives authorization. A "member" row, should be decoupled from membership (which you already stated you understand and agree with) which should be decoupled from subscription(s) which should be decoupled from payment processing details.

Good luck to you on that Jayfromsandiego. Try to post on Stackoverflow, or any of our myriad competitors. I certainly hope you will, if only so that you will find after the time it takes for you to register on each community and (re)post your "question" then wait for a response that may or may not ever come, only to find your question closed or ignored, or with a similar response to those you got here. This forum has a longstanding tradition of acceptance and hand holding that goes way beyond vast majority of programming forums that exist. As your question boils down to: "Here's what I want, code it for me?" don't be surprised when you get responses like ginerjm in even more blunt fashion. Meanwhile, NotSunfighter decided to take you up on your challenge and coded you up a solution. And just to be clear, noone (perhaps with the exception of NotSunfighter, after having spent valuable time trying to help you) cares whether you quit this forum. We are all volunteers. ginerjm may have been blunt, but he's right. We can all code. The vast majority of the people who answer questions like yours are professional developers. We are here to teach and share, and sometimes to simply tell someone the truth. The best I can hope for you at this moment is that you take a good hard look in the mirror at your own attitudes and approaches, and as the old saying goes "Don't cut off your nose to spite your face."

Alternative model which allows multiple siblings jdev_nroll; jdev_sibling; +----+--------+---------+-------+-----------+------------+ +------------+----------+ | id | sname | ctclass | shift | ctstudent | dob | | sibling_id | elder_id | +----+--------+---------+-------+-----------+------------+ +------------+----------+ | 1 | Curly | 1 | 0 | N | 2007-01-20 | | 2 | 1 | | 2 | Larry | 1 | 0 | Y | 2010-12-21 | | 3 | 1 | | 3 | Mo | 1 | 0 | Y | 2011-02-22 | | 3 | 2 | | 4 | Peter | 1 | 0 | N | 2009-01-03 | | 4 | 5 | | 5 | Paul | 1 | 0 | N | 2006-12-21 | | 9 | 8 | | 6 | Mary | 1 | 0 | Y | 2010-09-20 | | 9 | 10 | | 7 | Jane | 1 | 0 | N | 2008-03-08 | | 10 | 8 | | 8 | John | 1 | 0 | N | 2006-10-04 | +------------+----------+ | 9 | George | 1 | 0 | Y | 2010-10-26 | | 10 | Ringo | 1 | 0 | Y | 2009-11-15 | +----+--------+---------+-------+-----------+------------+ SELECT a.id as sibling_id , a.sname as sibling_name , TIMESTAMPDIFF(YEAR,a.dob,curdate()) as sibling_age , a.ctclass as class , b.id as elder_id , b.sname as elder_name , TIMESTAMPDIFF(YEAR,b.dob,curdate()) as elder_age , b.ctstudent as elder_ctstudent FROM jdev_nroll a JOIN jdev_sibling s ON a.id = s.sibling_id JOIN jdev_nroll b ON s.elder_id = b.id WHERE a.ctstudent = 'Y' ORDER BY a.id +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+ | sibling_id | sibling_name | sibling_age | class | elder_id | elder_name | elder_age | elder_ctstudent | +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+ | 2 | Larry | 9 | 1 | 1 | Curly | 13 | N | | 3 | Mo | 8 | 1 | 1 | Curly | 13 | N | | 3 | Mo | 8 | 1 | 2 | Larry | 9 | Y | | 9 | George | 9 | 1 | 8 | John | 13 | N | | 9 | George | 9 | 1 | 10 | Ringo | 10 | Y | | 10 | Ringo | 10 | 1 | 8 | John | 13 | N | +------------+--------------+-------------+-------+----------+------------+-----------+-----------------+

And if a child has a brother and a sister (or two or more of any gender)? [edit] There's this method, but it doesn't show explicitly that there is also a relationship between Curly and Mo too. SELECT * FROM jdev_nroll; +----+--------+---------+-------+-----------+---------+-----------+ | id | sname | ctclass | shift | siblingof | elderof | ctstudent | +----+--------+---------+-------+-----------+---------+-----------+ | 1 | Curly | 1 | 0 | 2 | | Y | | 2 | Larry | 1 | 0 | 3 | 1 | N | | 3 | Mo | 1 | 0 | | 2 | Y | | 4 | Peter | 1 | 0 | | 5 | N | | 5 | Paul | 1 | 0 | 4 | | Y | | 6 | Mary | 1 | 0 | | | N | | 7 | Jane | 1 | 0 | | | Y | | 8 | John | 1 | 0 | 9 | | N | | 9 | George | 1 | 0 | 10 | 8 | Y | | 10 | Ringo | 1 | 0 | | 9 | N | +----+--------+---------+-------+-----------+---------+-----------+ SELECT a.id , a.sname , a.ctclass , a.shift , a.ctstudent , b.id as bid , b.sname as bname , b.ctstudent as bstudent FROM jdev_nroll a JOIN jdev_nroll b ON a.siblingof = b.id; +----+--------+---------+-------+-----------+----+--------+-----------+ | id | sname | ctclass | shift | ctstudent |bid | bname | bstudent | +----+--------+---------+-------+-----------+----+--------+-----------+ | 1 | Curly | 1 | 0 | Y | 2 | Larry | N | | 2 | Larry | 1 | 0 | N | 3 | Mo | Y | | 5 | Paul | 1 | 0 | Y | 4 | Peter | N | | 8 | John | 1 | 0 | N | 9 | George | Y | | 9 | George | 1 | 0 | Y | 10 | Ringo | N | +----+--------+---------+-------+-----------+----+--------+-----------+

I'm not concerned about it because it doesn't have to be. Like you said, you feel like it has to be a certain way. I'm telling you that no, it does not. It's something separate from this to consider doing, but one that I recommend. But if you do it then you'll simplify some of this problem. No, what you're doing is allow anonymous access. I'm saying allow authenticated but non-premium access. Give like 20% access for anonymous users to get people to the site. Allow 30-40% access, plus maybe a couple features, for authenticated users to get people to sign up. Allow 100% access for people who pay money. This here is some fairly basic economics about funnels. Let people ease into your site until they're comfortable with the idea of paying money; making it a single step of "30% access and you have to pay to do anything more" is a cut-off that is going to lose you customers. Allow unpaid access. Give people who are interested in your site another step they can take that doesn't require them to pull out their wallets. Because you're fixated on the whole "omg it's all at the same time" thing that I keep telling you it is, in fact, not the case. No. It's dumb, but it's not a sin. I don't see how what you're describing now is different from what you were talking about originally. Before you wanted to do everything "at once". Now you want to do everything "at once". It's the same thing, just different words. 10 concurrent users is nothing. It's unlikely to happen, of course, but when you have everything "at once" taking a long time then you have to care more. For varying definitions of the word "slim". Congratulations. But you're describing stuff that everybody does differently. And they do it differently for a good reason: because it works better. You aren't anywhere near a point where you can run A/B testing to discover for yourself what works better and what does not, so maybe set aside your own designs and take a look at what other websites do. Because they have done the testing.

Depending on your business needs, sure: you could do all of those at the same time. But you're approaching this like it's all-or-nothing. It isn't. You can create the user regardless of the transaction. You can record the order regardless of whether the payment goes through. Don't treat it like it's all one big operation that you have to rollback/cancel if any one step fails - make each part work in its own right, just like if the user was in control of each step.

I've not used any of the listed options. The couple API's I've worked on have just used Symfony since that's what I typically use for other applications. It's worked fine for me for the most part. There are various bundles dedicated to implementing REST API's that may be useful (ie, FOSRestBundle).