update

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 would get a bunch of errors:

Warning: Attempt to assign property of non-object in /home/flk/vhosts/kolaz.techarena.co.uk/modules/actions/actions.inc on line 17