my self-inflicted hell (a cautionary tale - also, HELP!)

[Kindred]

Settings.php1  ??

that file is not created by SMF
SMF updated Settings.php or created php~ files... but never php1 files

[margarett]

We really need to start splitting up these "sub-questions", I'm starting to think that I'll be missing stuff

I think it's a vanilla theme, but I manually customized it, tweaking the colors and changing the bitmaps used.

The default theme from 1.1.x (especially beta!) is far, far different from Curve (SMF 2 default theme)

then at some point my CSS skills improved

It's an excellent time to "massage" these skills again

The hard part is maintaining my original customer database without hooks into your payment feature.

Question: why can't you keep your current payments system? Or is that system SMF-based?
Better yet, what payment system is it and how does it work? Sordid details are appreciated

Question: My paid-access code checks whether the person paid by check (and thus there is a 2-3 day wait). I don't give access until the check clears. It's automated in my PayPal response script. Does SMF do that?

As far as I know, not. But I am really a n00b in paid subscriptions, never actually used them

There is one feature I have in my paid-access code that SMF doesn't (and at least I don't see it). I could give members a free trial for 7 days or whatever. I'm not currently using this, just mentioning it as a feature suggestion.

SMF *CAN* do a "free trial" sort of thing, it just won't handle "autoconverting" them to the full paid....

Actually it can. I guess that the OP would be interested in the "how"?
It's fairly easy actually. You just need a non-standard feature but which can easily implemented, together with whatever system you use for the paid subscriptions.
a)when a member subscribes (by whichever means you implement ) you change them to a membergroup (eg: "Full Member" or whatever). This means that a non-subscribed member will have no primary membergroup
b) You implement a scheduled task which runs once a day and gets users without primary membergroup, registered over 7 days ago. If found, shazam, wipe them!
Problem: this doesn't remove the already available payment at Paypal. If someone pays them after being auto-shazam'd ( ) you have to manually fix the mess (but I guess that also happens now, right?)

I looked at repair_settings.php and I see why it wasn't finding my database settings. There are a bunch of database variables in Settings.php that SMF names db_* (db_server, etc.). In my customized version of SMF, I changed this to $smf_db* ($smf_dbserver, etc.), because I use two different databases and I didn't want ambiguity in the code about which I was using

This is seriously a bad idea... Your issue with repair_settings is just an example. Why not keep the default? $db_name, etc, is only used throughout SMF itself so it should cause no conflicts with your other software. Not?

. I don't think this is due to my changing some variable names because everything else in the script is working fine

Most likely it is... repair_settings is, in all honesty, in serious need of a complete rebuild. From scratch. SMF itself is not easily "abstractable" (does this word even exist? ), let alone an ancient version as 1.1 beta-something, and repair_settings even less.

For starters, there appears to be a typo in the first line - shouldn't $UserdDir be $UsedDir (no extra r)?.

There is. I'll fix that, thanks.

Anyway, you can live without fixing attachment folder through repair_settings You can just fix it in your admin panel after you move all other important settings If you can't use repair_settings, you can manually fix paths. It's a bit more laborious, but is is possible

When you do upgrade to 2.0, you *should* start by fixing this. Make sure you leave Settings.php with the default variable names. In fact, unless you want to fix the upgrader itself it won't even work with these names...

[permutations]

Settings.php1  ??

that file is not created by SMF
SMF updated Settings.php or created php~ files... but never php1 files

This file is being automatically created, and the only thing in the subdomain is SMF - I just created it last night specifically for SMF upgrade testing. I can't think of anything else that could be creating it except SMF (or a tiny elf inside the server, of course).

The hard part is maintaining my original customer database without hooks into your payment feature.

Question: why can't you keep your current payments system? Or is that system SMF-based?
Better yet, what payment system is it and how does it work? Sordid details are appreciated

I wrote it myself with PHP and MySQL - all kinds of weird joins so I could see my sales over time and split out in different ways. It accesses a relational database with 8 tables: customers, downloads, orders, order_items, price_list, product_list, subscriptions, and subscription_pmts. If all my forum access sales don't get recorded into this relational database, my accounting script won't give me accurate sales information.

I have some worries about how the SMF payment system is implemented. If it snaps up all the PayPal APN notifications, I won't be able to use it. I'll have to reattach my own system to the SMF update (pain!). At the time I wrote my fork, the only forum software that had a payment feature was vBulletin, but (1) it was butt-ugly, and (2) it took over all interaction with PayPal so I couldn't sell other things on my site. That's why I wrote my own custom implementation. I hope I don't have this same problem with SMF 2.0. There is a warning that if the PayPal APN feature is turned on, it will cause SMF error messages. That worries me. I'll find out for sure how much of a problem it is (or if it's a problem) when I try to use it. I hope it is flexible enough to work for me, with the other things I sell on the site (and my accounting system).

Question: My paid-access code checks whether the person paid by check (and thus there is a 2-3 day wait). I don't give access until the check clears. It's automated in my PayPal response script. Does SMF do that?

As far as I know, not. But I am really a n00b in paid subscriptions, never actually used them

Uh oh. This is important - pending payment is not payment. Access to my forum gives access to other resources on my site. I hope SMF does this right. I'll soon see!

There is one feature I have in my paid-access code that SMF doesn't (and at least I don't see it). I could give members a free trial for 7 days or whatever. I'm not currently using this, just mentioning it as a feature suggestion.

SMF *CAN* do a "free trial" sort of thing, it just won't handle "autoconverting" them to the full paid....

Actually it can. I guess that the OP would be interested in the "how"?
It's fairly easy actually. You just need a non-standard feature but which can easily implemented, together with whatever system you use for the paid subscriptions.
a)when a member subscribes (by whichever means you implement ) you change them to a membergroup (eg: "Full Member" or whatever). This means that a non-subscribed member will have no primary membergroup
b) You implement a scheduled task which runs once a day and gets users without primary membergroup, registered over 7 days ago. If found, shazam, wipe them!
Problem: this doesn't remove the already available payment at Paypal. If someone pays them after being auto-shazam'd ( ) you have to manually fix the mess (but I guess that also happens now, right?)

Oh, for shame. Kludge!! Free trials are a PayPal feature. You pass the correct parameters to PayPal and it's seamless. After 7 days free access, the person is automatically charged, unless they cancel their membership before 7 days are up.

I looked at repair_settings.php and I see why it wasn't finding my database settings. There are a bunch of database variables in Settings.php that SMF names db_* (db_server, etc.). In my customized version of SMF, I changed this to $smf_db* ($smf_dbserver, etc.), because I use two different databases and I didn't want ambiguity in the code about which I was using

This is seriously a bad idea... Your issue with repair_settings is just an example. Why not keep the default? $db_name, etc, is only used throughout SMF itself so it should cause no conflicts with your other software. Not?

I promise I will never do it again. Definitely not worth the pain. 

Anyway, you can live without fixing attachment folder through repair_settings You can just fix it in your admin panel after you move all other important settings If you can't use repair_settings, you can manually fix paths. It's a bit more laborious, but is is possible

I have all my paths set correctly. It wasn't actually a problem for me. I just mentioned it in case it was useful feedback.

When you do upgrade to 2.0, you *should* start by fixing this. Make sure you leave Settings.php with the default variable names. In fact, unless you want to fix the upgrader itself it won't even work with these names...

I promise not to change any more variable names ever again. Waaay too painful!! I am now forward-thinking. I will be very mindful of the possible future need to upgrade. 

I'm trying to work up my nerve to do the upgrade. Everything is ready. I just have to copy the files over - very carefully, directory by directory, so I don't blow away any content. It's a cloned site, plus I have backups of both the database and the files, and yet I dread doing this. It will be such an ugly mess after, with so much to fix. 

[margarett]

This file is being automatically created,

I have absolutely no idea how that can happen

I wrote it myself with PHP and MySQL

I am *pretty* sure that it can easily changed to work with 2.0. Most table names are the same, most column names are the same (just not capitalized as in 1.1), most functionality (membergroup-wise) is the same.

I have some worries about how the SMF payment system is implemented.

I can't really help you with that as I don't really know it in deep. But if I'm right about my previous point, you should be able to use your own system so this is not a problem

Oh, for shame. Kludge!! Free trials are a PayPal feature

Again, really sorry, maybe it works (or not ), I just don't know...

I just have to copy the files over - very carefully, directory by directory

It's a duplicate. Just blow it away
Joking a bit, but not that much. You should *really* remove everything in Themes and Sources so that no leftovers are kept... I'm not yet sure what's the dimension of your integration but:
- theming has to be made again. Period
- paid stuff might be possible to use with your own system out of SMF. So probably nothing too much to do there (or so I hope )

So it's probably no use in uploading file by file, wasting time and probably leaving files behind which should not be left behind...

[permutations]

The tables that make up my customer database have nothing to do with SMF. These are custom tables that I created myself that store all my product information, pricing, special offers, etc. The PHP/MySQL program I wrote to access it tells me how much money I'm making every month, and from which income sources. I'm self-employed - this site is how I make my living. I really need to know how things are going.

So it's probably no use in uploading file by file, wasting time and probably leaving files behind which should not be left behind...

I understand, but I do have to be a little careful. This is a complicated site, and if I'm careless about it and have problems, I'll have no idea why. I want to know exactly what I'm deleting and exactly what I'm keeping. There is a lot more on this site than the forum, and it's all tightly integrated.

I still haven't done it. I watched a movie.   I'll do it now.

[margarett]

Ok, allow me some more curiosity please

In your current system, how do you grant forum users access when they perform the payment?

[permutations]

Ok, allow me some more curiosity please

In your current system, how do you grant forum users access when they perform the payment?

Ask away - I'm happy to explain. I accept only PayPal. I use PayPal's APN capability. The e-commerce code on my site is completely custom. There was no product that could do everything I wanted, and I like coding so I just wrote it. When customers make a purchase on my site - of anything - I send them to PayPal to pay with a whole lot of $_POST data that has the order number, product ID, price, etc. When the customer completes the payment, PayPal sends me a notification with a whole lot of information - customer name and address, transaction number, price paid, method of payment (instant or echeck), paid flag (0 for an uncleared echeck), and my custom fields (order number, product ID, option codes, etc.). The PayPal notification goes to a script on my site that does all kinds of processing. The sale is recorded in my customer database (some additional tables I added to the SMF database that have nothing to do with SMF - don't even use the SMF prefix).

I sell lots of different things, so depending on what they bought I have to do different processing. The main thing I sell is myself - I consult with people. I also wrote a book which I sell both in paperback and ebook form. The paperback I have to actually fulfill, but everything else is automated. I wrote some tricky code for the ebook download that hides the files until someone buys it, then pulls it from an off-web place and renames it to the person's transaction number. But when the customer downloads it, it looks like it has the normal name. Their ebook is deleted from the server after 3 days. There was some other PayPal feature I had to use for the ebook downloads - I'd have to look at the code to remember what it is.

I offer a number of different options for forum access. I've changed the pricing of the forum many times. What I've got now seems to work pretty well. Pricing is very tricky. People can buy 1 month at a time, 3 months, 6 months, or lifetime membership. The limited time options are implemented as nonrenewable PayPal subscriptions with no free trial (these are just PayPal parameters). The lifetime membership is implemented as an order, rather than a subscription. If the person uses PayPal instant payment, my script gives them instant access. If they use an echeck, I wait for the PayPal APN notifying that the check has cleared, and then give them access.

The payment part for the forum comes after registration, so I have a "pending" table that holds the registration until PayPal's notification says they paid. Then my script completes the registration. If the notification doesn't come within x amount of time (configurable), the pending registration is deleted. I do it this way because once they are halfway through the registration, marketing wisdom says they are more likely to complete the payment because they're committed. I don't yet know how SMF does it.

My code automates all things related to sales, but I didn't bother to create lovely interfaces for things like adding new products. I just use phpMyAdmin - that's a good enough interface for me. I also change offer codes, etc., directly in the php file - no interface. It's trivial for me to edit a php file, and I don't need it to look pretty. But this makes my system not "mod-able". I'd have to create pretty interfaces for all this stuff - lotta additional work that I don't personally need, so it doesn't interest me. 

This is probably way more than you wanted to know. 

[permutations]

I'm moving the SMF 2.0 files in, directory by directory. I just noticed that my attachments directory contains a whole bunch of avatar pngs. Why are they there instead of in the avatar directory? The avatar directory just has stock pictures of actors and musicians. Was this a bug in SMF 1.1 Beta 3?

[Kindred]

The attachments directory is used for a users custom avatar, by default. The avatar directory is used for server supplied avatars.

Smf can handle the forum payments very similarly...   A user subscribes to a group which you have defined for a time period and a price. They get access when PayPal responds with a paid notification.

[permutations]

I just found something in my code about name collisions. It's coming back to me. I didn't go through the pain of changing those SMF variable names for no reason. There was a problem. I was using something on the site that used the same variable names that SMF uses. I can't remember what it was - I do remember the problem.

I really wish that SMF would not use such generic names for its database variables. Is there somewhere I can make this request? I'd have to study my code to remember the details of the problem I encountered, but I do remember it was an ugly problem.

[permutations]

Kindred, do you know if the SMF payment system "eats" all the PayPal notifications so I couldn't do any of my own handling? If so, no matter how well it handles paid access to the forum, I cannot use it because I sell other things on my site. It would be so difficult to integrate my other e-commerce code into the SMF code that I'd rather just copy over my whole payment system. The PayPal response script is the trickiest code on my site, and it's murder to debug because of the interaction with PayPal.

[permutations]

Ugh. This did not go well at all. The forum was in maintenance mode when I ran update.php. I was immediately locked out because of that - couldn't see anything happening from the update script. I edited Settings.php to set $maintenance to 0, and now it says it can't connect to the database. I get that on every page. I have no idea what happened.

I removed ALL my custom files and replaced them with SMF 2.0 code. But all I get is a blank page with an error message: "Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later."

[live627]

You probably overwrote Settings.php   which made SMF lose database settings.

[permutations]

I solved the connection problem (some lingering changed db variable names), but I have another problem. I get this error message when I try to run update.php:

"Unknown column 'a.attachment_type' in 'field list'"

There is no script name or line number associated with this error message, and the string "attachment_type" does not appear anywhere in update.php. I looked at the attachments table, and the variable is called attachmentType, not "attachment_type", but I can't find where to correct this in the code - I don't know where the error message is coming from. (Naughty programmer - should give script file name and line number!) Maybe I'll just change the field name in the database.

Perhaps this update script doesn't account for SMF 1.1 Beta 3 - maybe the field name changed in the release of SMF 1.1.

-----------

Edit: Changing the field name in the database got rid of the error message, but now I'm staring at a blank page - nothing. This is bad. I'm going to have to put debugging messages all through update.php to figure out what's going wrong. Ugh!!!! Can't even this part be easy???

[margarett]

Upgrade wasn't performed (probably due to the variables names). Restore the database field and run the upgrade again

edit:

"Unknown column 'a.attachment_type' in 'field list'"

This is the error you get when you reach 2.0.x index.php without having performed the upgrade. So you probably didn't reach upgrade.php (you mention update.php, typo?)

Upgrade.php doesn't trigger this error, index.php does

[margarett]

This is probably way more than you wanted to know. 

Thank you for the explanation. It's more than I wanted to know but, especially, it's not what I wanted to know

You seem to have great control over your payment process. My honest opinion is that you should keep it. As I told you, I'm not very into SMF's Paid Subscriptions but I am pretty sure that it will not replace your current system without *major* overhaul...

What I still want to know is: how do you grant forum users the "special access" after they complete payment? And how do you withdraw it if they don't renew the payment?
Where exactly do you interact with SMF's tables in the payment process?

[permutations]

"Unknown column 'a.attachment_type' in 'field list'"

This is the error you get when you reach 2.0.x index.php without having performed the upgrade. So you probably didn't reach upgrade.php (you mention update.php, typo?)

Upgrade.php doesn't trigger this error, index.php does

Augh! This is what happens when you try to do things at 1am. I was typing "update.php" rather than "upgrade.php" as the script name. It works fine when I actually access the script. 

Thanks!

[permutations]

I can't get upgrade.php to do anything. When I click Continue, I just get the same page again.

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

Edit: I found the problem - Settings_bak.php was missing. I'm getting a warning that it could take hours to update because the forum is large.

[permutations]

Uh oh - the upgrade is stuck on Step 4 - database changes. Bad step to get stuck on. Here's what it says:

Executing database changes
Please be patient - this may take some time on large forums. The time elapsed increments from the server to show progress is being made!
Executing upgrade script 1 of 2.
Executing: "Updating search cache..." (14 of 19 - of this script)

Updating indexes on "messages"...done
Updating table indexes............done
Reordering boards and categories...done
Updating indexes and data on "smileys"...done
Updating indexes on "log_boards"...done
Updating indexes on "log_mark_read"...done
Updating indexes on "themes"...done
Updating data in "settings"...done
Adding new settings...done
Adding PM spam protection settings...done
Cleaning old values from "settings"...done
Encoding SMTP password...done
Adjusting timezone settings...done
Installing theme settings...done
Renaming personal message tables...done
Updating indexes on "pm_recipients"...done
Updating columns on "pm_recipients"...done
Updating columns on "members"...done
Updating columns on "members" - part 2...done
Updating member approval...done
Adding new holidays...done
Updating event start and end dates...done
Converting other date columns...done
Checking for an old table...done
Creating "message_icons"...done
Inserting "message_icons"...done
Creating "package_servers"...done
Inserting "package_servers"...done
Updating flood control log...done
Updating ip address storage...done
Converting "log_online"...done
Updating poll column sizes...done
Updating attachments table...done
Updating boards and topics...done
Updating members...done
Recounting member pm totals (step 1)...done
Recounting member pm totals (step 2)...done
Converting server stored setting...done
Converting avatar upload setting...done
Updating attachments...done
Updating settings...done
Registering thumbs...done
Adding image dimensions...done
Splitting ban table...done
Updating ban statistics...done
Deleting some very old permissions...done
Renaming permissions...done
Upgrading "deny"-permissions...done
Upgrading post based group permissions...done
Upgrading by-board permissions...done
Removing all guest deny permissions...done
Removing guest admin permissions (if any)...done
Creating search cache tables...done
Rebuilding fulltext index...done

Error!
Server has not responded for 30 seconds. It may be worth waiting a little longer or otherwise please click here to try this step again

I clicked "here" to have it try again, and it got stuck again in the same place. I don't have any idea what the problem could be or how to fix it. Help!

[margarett]

That usually means that the server "died" on you during some extensive (and heavy) database operations.

Nevertheless, in some setups it just takes longer than the script is prepared to wait.
Check this topic for a possible fix
http://www.simplemachines.org/community/index.php?topic=533314.msg3790994#msg3790994