update

I'm not sure if the e-commerce module is affected by this change/update but we just received this email the other day about some major changes on how Authorize.net is handling transaction id's. Not sure if a patch needs to be created or not.

<

blockquote>Dear Authorize.Net Merchant:

In early October, Authorize.Net will be expanding the range of Transaction IDs issued by the payment gateway. Please read this e-mail thoroughly as it contains important information on how to ensure that your account is not affected.

I have a custom module I inherited that implements its own CCK widgets to import videos, and the widget stores multiple columns in the database, but to the user, it all seems like one field.

I recently decided we needed to add a column to refer to the thumbnail, so I edited my 'database columns' operation in the hook_field_settings() function, and added a line in the hook_field() function, along with the logic I needed to fetch, display and validate the data.

I've spent a few hours this past week cleaning up the module and made new tarballs, it still needs some testing but I will probably try it on a production domain tonight. The main change is really that the code is more tidy and only uses session keys rather than autologin cookies, but the update also makes it possible to access Drupal's user profiles. I think it's also good enough to start the work on Drupal 6.x. Some of SpectralDart's work will have to be redone, but the clean up was worth it.

Here is what has changed:

Hello all,

I have Drupal 5.3+phpbb2.0.22 integrated using phpbb5x-1.1 module,

I seem to have an interesting problem: when editing user profile, I can successfully update such fields as user_from, user_icq, etc. both in the drupal users table and in the phpbb users table. On the otherr hand, when I want to disable notifications about new posts on the forum -- "disable notifications" unclicked in the profile -- the change is happening only in drupal_profile_values table and not in phpbb_users table.

I have updated the beta to fix the issues Jason pointed out. The .htaccess file no longer makes mod_rewrite look for user. Instead I have introduced a new permission called 'edit drupal users'. If your role has this permission then you will not be redirected to the phpBB profile.

If you modify usernames, email, password or pictures through Drupal you will end up with a mess in your database. Therefore only key admins should have this permission.

Last weekend I spent more time on the design document, I also spent time playing with many various modules to see about integration with the extend case tracker module. I have been working on a mock design and how things will function and integrate. I also started looking at all the existing case tracker module code to see how things are interacting with other modules and what type of functionality exist there. I had a discussion with yoroy and with Dave Notik (sponsor of the case tracker module) about usability and design.

There is one thing that I have to say that is the progress is quite slow. Most of the code written was refactoring and organizing the interface. Below are some notes:

• I have made an XPI file. It's still a prototype. I think I'll need a lot of time before I can turning it to something useful. I also plan to drop support for remote xul with the subsequence version because there're some functions that need to be done in full priviledge mode (such as settings persistent, access to files, etc ...).
• Help needed : Is there any tip of writing Drupal's RPC interface? It's quite time consuming as I have to dig through the code and find wich snippet to copy and modify. There's not many cases where just some function calls is enough. The rpc interface can be done this way but I fear that there will be a lot of redundant code.

Heya guys,
sorry i havent posted in a long while but god the time just flew by (so much to do, so little time).

God how horrible it is to code during boiling summer (omg its totally boiling here....i soo miss the rain :P)
Over this period i have had quite few problems which when i look back seem so simple such as understanding that actions_do() accepts an array of actions and a loaded node(node_load($nid)) not just node id.
so whenever i ran something like:

I'm thinking about a database which is storing:
- Project name
- Download file
- Module name
- Date
- MD5 and SHA1
- Module description
- Drupal Version
- README.TXT or INSTALL.TXT
and programming an interface (module) to check these against your own installation.

What I need is to download all "[PROJECT].tar.gz" files and import these into a database. This was the easy job (simple devel example).
Currently this is done with a CCK designed table, but I will switch to an own node-type cause of some CCK restrictions (e.g. search).

the next two steps are writing:

OK, for the past few weeks i have been reading around different area's such as the form api, _cron hooks etc.
At times i could see what was happening and other times... i was totally lost.

For example for the past week or so i have been working on updating schedule module to work with 4.7.
So far i have built most of the form (god, how i wish i knew about lullabots formupdater before i began this ;P)
but i have been stuck on one single issue form_set_value() (http://api.drupal.org/api/head/function/form_set_value && http://drupal.org/node/51104 ) which allows for setting values to the form elements during the _validation stage.