As long as the second installation is password protected then he can, otherwise he can't Well, at least you've got template modifications you can use in the newer versions.
Xenforo's template merging is surprisingly okay. It'd need bits done manually, but using a test installation to fix the theme up pre-upgrade, it's not actually as bad as you'd expect. The fact that the theme EMC uses is available for 1.4 makes it even easier. Only thing that I can guarantee break is the default registration form, which EMC doesn't even use.
An API without any changes to the Forum would be very helpful and appreciated. It would be also very helpful if the transaction records would have (besides what is now seen in the list) - Residence ID (for the future - I guess the residences / claimed land in the wild will have IDs / numbers too) - Full transaction time (UTC) (to the second at least, I guess it's already there in the DB) - Perhaps a transaction ID which would monotonously grow (to provide identity and ordering for transactions - I assume they already have that) If a small addition to the forum is acceptable, it would be display of a "Transaction API Token" which would allow external Apps to access transaction data of that user until the user changes his/her forum password - the token would then also change automatically.
I'm still somewhat confused. If an API is built, what exactly will break when the XenForo update occurs in the future? The API output would be plain text (for a machine, not a human) and thus no layout. It can grab data straight from the database and should not even need to go through the XenForo software. The API key can also be checked directly from the database without any use of XenForo either. You should be able to read from the XenForo user table directly. When the update occurs, create a copy of the user table that the API can use during the update process. Alternately, have a separate table to link usernames and API keys. Unless I'm missing something, it's only the API retrieval/regeneration which needs to be secured within XenForo (to ensure that the user is authorized to retrieve/regenerate their key). In which case, it's not a big deal if that system is down for a period of time. As long as the other systems work, business can go forward as usual for existing user/application relationships.
As I understand, any addition to the Forum now (even a very small one) means it needs to be checked / tested in the new version. This two small additions here would be - generate and store an API key / token always at the same time when the member password is set - show the API key / token at appropriate place in the forum (next to the rupee balance) For the API, I'd suggest two simple functions with a simple HTTP(S) post which would return XML structure: get_transactions_summary(user, token): <transaction_summary> <timestamp_utc first="..." last="..." /> <id first="..." last="..." /> <count value="..." /> <balance value="..." /> </transaction_summary> get_transactions(user, token, optional start_id, optional end_id, optional start_timestamp, optional end_timestamp): <transactions> <transaction id="..." timestamp_utc="..." type="..." residence="" amount="..." item="..." player="..." item_count="..." description="" /> <transaction ... /> ... </transactions> This would return the list of transactions, which could be limited to a max number of entries per query (perhaps like 3000 or so), with filter (any of the terms are optional) id >= start_id AND id < end_id AND timestamp >= start_timestamp AND timestamp < end_timestamp optional transaction elements: - amount (can be omitted for notices) - item, item_count (only there if buying / selling an item) - player (only when there is another payer involved) - description (omitted with usual transactions) - residence (res #, frontier of each server could also have res # etc.) types: - purchase (from a chest-shop of a player) - selling (to a chest-shop of a player) - shop-sells (to a player) - shop-buys (from a player) - payment (to / from a player, amount is positive when receiving rupees) - notice (no balance change, notice is in the description) - bonus (login bonus, voting, referral, ...) - fee (vault fee, stable fee, locking fee, unlock refund, force claim fee etc.), amount is negative when paying to EMC, positive for unlock refund - adjustment (e.g. adjustment through an admin)
Alright, My site is DOWN because of the CPU usage. The culprit, direct from the server logs I was given, is the script to read the rupee histories. It takes a lot of CPU to connect to a website and complete an authentication, and then to parse a large string. I can work on making the script more efficient, but ultimately I would much, much rather read a single URL and run a simple json_decode or xml_parse or str_getcsv, where there are libraries, already built, which are much more efficient than anything I could ever code, and there are significantly less conditions I have to account for. Not to mention I have dozens of people who've requested me to get their rupee history and I'd really love to be able to get that information live to create faster price adjustments, which I can't do with the current system. I don't want users to have to repeatedly enter their sensitive login information to keep the prices up to date.
