Reliable, affordable and high-quality phpBB services and consulting since 2006
This version includes a one-click unsubscribe link that should help reduce issues with digests going into spam folder. Learn more about the release here.
It can be downloaded from the digests extensions page or from the GitHub release branch. If downloaded from GitHub, make sure to place the software in the /ext/phpbbservices/digests folder.
Read the changes here. The Edit Subscribers page has been revamped.
You can download this version from my digests extension page or from the GitHub branch page. If downloading from Github, make sure to place it in the /ext/phpbbservices/digests directory.
See this topic for more information. You can download it from my Smartfeed page.
Recently I accepted a cryptocurrency payment. I did it mostly to learn the process, advantages and pitfalls first hand. The process was straightforward, although it did require getting a digital wallet and setting up an only crypto account. I chose Exodus for my wallet and BlockFi as my broker.
I’m still evaluating the extent to which I want to accept crypto payments. Cryptocurrencies have certain advantages. For example, for certain international customers, it’s a relatively easy way to pay me or perhaps the only way to pay me, although certain countries like China restrict cryptocurrencies. Assuming the value of the cryptocurrency rises, it can also be something of an investment. I got a 25% return on the bitcoin I was paid in over one month. Of course cryptocurrency prices can vary widely over short time periods, so it’s just as easy to lose 25% in one of these currencies over a given month too.
They also have certain downsides. You can’t buy much with cryptocurrencies, so to spend the “money”, you have to sell it in your local currency and move it into a traditional bank account. Also, the price of cryptocurrencies can fluctuate wildly over time. A currency of value doesn’t fluctuate that much over time, which is why I’ve only accepted U.S. dollars until recently. So to my mind these cryptocurrencies that exist outside of regulation and are subject to supply and demand really aren’t currencies.
The client paid me in bitcoin. bitcoin is a “dirty” currency in that it requires a lot of electricity to create new bitcoins. It’s estimated the electricity used just in creating bitcoin is equal to the electricity consumed by the Netherlands. Most of this electricity comes from carbon-burning power sources, contributing to climate change and global warming.
Consequently, if I accept payment in cryptocurrencies in the future, it’s going to be in more environmentally benign and relatively stable cryptocurrencies. Right now, ethereum qualifies.
My services will still be priced in U.S. dollars. You would have to pay me the equivalent in ethereum. But I do want to be clear that I don’t want to be paid in ethereum or any digital currency. If you can pay me in U.S. dollars, that’s what I prefer. In some cases though not accepting ethereum would be unprofitable, so I will make exceptions.
Assuming I accept cryptocurrencies for work I do for you, I will provide an address you can use to pay me at the appropriate time.
I kept plenty busy in July. Like most months for the last year or so, much of my work was focused around one commercial client.
Our main accomplishment this month was finally finishing up a custom OAuth interface to phpBB. The interface ties into many aspects of the business including a shop and accounting system with many points of entry all of which had to work consistently and reliably.
You may be familiar with OAuth if you go to sites where you can login with Google, Yahoo or other major web sites. OAuth allow for an external service to authorize your access on a different site through a complex exchange of codes and tokens. phpBB supports only three OAuth services natively: Google, Facebook and Bitly.
The client’s backend OAuth system is definitely a “roll your own” service so it required lots of low level integration challenges. I’ve learned plenty about OAuth in the process, enough to realize that it’s challenging, very low level and not for the faint of heart.
Toward the end of July we buttoned up we hope the last of the code changes needed but discovered a new area: mobile device display, that had been overlooked. So I am now deep into more styling work, which is where I started the project back in March 2020. Once this is done we should finally be at a code complete event, and the work will go into formal testing.
At this point I’m probably 80% of the way through the project, which has been challenging but very profitable. Working with one of their lead developers has been a great and at times humbling experience.
Here’s a summary of work I did for other clients in July:
Having experimented with putting my Mastering phpBB Administration book on Lulu.com, the book is now back for sale on Amazon.com and I retired it from Lulu.com. You can buy the paper book (338 pages) for $19.99 here. Note it’s also for sale as a Kindle eBook for $9.99 here. Links are also in the sidebar ad and appended to every page and post. This version is fresh and covers up through phpBB 3.3.4.
The eBook is enhanced as I took the time to convert it to an ePub format which allowed me to do things like fix issues with some embedded screenshots and create a usable linked table of contents. Amazon converted the ePub version to its proprietary Kindle version, so only the Kindle version is available as an eBook.
I moved it from lulu.com because after months of trying to update the eBook format and getting no support from their support team, I realized they just didn’t care enough to fix the issue, plus I couldn’t offer the eBook with new content. I’m no fan of Amazon, but at least their publishing process is reliable if a bit cryptic.
This version is good enough to submit for approval. It has a release candidate status. Details are here.
It can be downloaded from the spam remover extension page or from the GitHub branch. If downloaded from GitHub, make sure to place the files in an /ext/phpbbservices/spamremover folder.
Notes on the release are here. In particular note that:
It can be downloaded from my digests extension page or the branch’s page on GitHub. If downloaded from GitHub make sure to follow the procedures for disabling the digests first and replacing the files correctly. From GitHub, place the files in the /ext/phpbbservices/digests folder.
Work in June kept me pretty busy.
As with most months since the start of the pandemic, one primary client occupied a lot of my time: 42.5 hours for this commercial client. Working with a key developer, we continued work on a custom OAuth extension. The extension ties into the client’s authentication system. I’ve learned much more about OAuth as a result than I ever expected (or wanted) to learn.
At the start of the month we concentrated on feature that when you sign out of phpBB you are also signed out of the site’s authentication system using OAuth methods. In addition a handshake was needed so that if a user was removed in the authentication system, the user was also automatically removed in phpBB. A method was also needed to ban the user on a signal from the authentication system, either permanently or for a fixed period. In the process there was some code clean up and centralizing of common logic into a common extension, called as needed by other extensions.
Toward the end of the month we worked on the issue of logging in indirectly, such as by logging into the accounting system first then going to the link to the forum and logging in automatically. It was all pretty confusing and hair tearing at times but we eventually got it to work. So most of the custom OAuth work is now done with some tweaks remaining, mainly to intelligently handle logging into the ACP by checking OAuth for proper authorization. Hopefully that will be figured out in July.
In work for other clients in June:
More in the July report.
A client recently sought me out. A board user wanted to get email notifications when receiving private messages. These are disabled by default but can be enabled. Most users though won’t dig through the User Control Panel to find the setting: UCP > Board preferences > Edit notification options > Someone sends you a private message > Email.
The client wanted all his board users to have this enabled by default. Not one to ever reinvent the wheel, I searched for an extension. I found this one, in release candidate status, which allows an administrator to tweak notifications for a user on a case by case basis. But that didn’t meet the requirement.
I wasn’t sure how this setting was stored in the database. I did some experimentation by turning it on and off and looking in the phpbb_user_notifications table using phpMyAdmin. This provided a clue on what to do.
Essentially if I could add rows like this to this table, I’d effect the change needed. There were two aspects to this:
If you know Structured Query Language (SQL) pretty well, it wasn’t that hard to figure out the SQL needed to ensure existing users who didn’t have this setting applied had it applied. This amounted to adding rows to the phpbb_user_notifications table for those who didn’t have a row for this permission already. The SQL was little complex but based on what I learned from testing in phpMyAdmin, straightforward and turned out to be:
INSERT INTO phpbb_user_notifications
SELECT ‘notification.type.pm’, 0, user_id, ‘notification.method.email’, 1
FROM phpbb_users
WHERE user_id not in
(SELECT user_id FROM phpbb_user_notifications WHERE item_type = ‘notification.type.pm’ and method = ‘notification.method.email’)
AND user_type = 0;
Having it work automatically with new registrations though was more complicated. Initially I didn’t consider the idea of writing a phpBB extension to do this. Rather, I proposed writing a SQL trigger to do this instead. But then I realized writing an extension would probably not be that big a deal and would have the advantage that if the user was deleted, phpBB’s code would delete these user notifications at the same time.
Writing extensions for phpBB is complex the first few times you try, as I discovered. The phpBB Group has this Wiki you can read to see if you can get your head around it. You need to be able to program in PHP but really you also generally need related web stills in HTML, CSS and Javascript too.
The more extensions I write though, the more I realize a lot of rather simple functionality can be done with rather trivial extensions. There is a skeleton extension you can install that will generate a lot of boilerplate code that makes it relatively easy to add the specialized functionality you need. I placed this on my test board and simply filled out the fields needed. Once installed a link appears on the navigation bar. The most baffling part for new extension authors is figuring out which components to check. Much of this comes from experience, but hovering over the component with your mouse helps explain that the component will do for you.
In this case, all I really needed was to check the PHP event listener and service checkboxes. This was for a client so it was not for general release, so I didn’t need to worry about database migrations. I didn’t need to add any Administration Control Panel user interface. It was to happen behind the scenes. When the form is submitted it creates a nice .zip file which can be decompressed and uploaded to your development environment. I enabled the extension.
What I needed to do was to add some logic during user registration. But where? And how? phpBB is all open source, so it’s a matter of reading the code. If you read the code, you realize that at some point the function user_add in /includes/functions_user.php is called and it does the grunt work of adding new users to lots of tables.
Inspecting the user_add function I found inside it a number of events that could be hooked into by my extension. I found the core.user_add_after event at the bottom of the function that looked like it would work. Essentially, after phpBB does all the normal stuff to create a user, you can have it do extra work. The event documentation shows:
/**
* Modify the notifications data to be inserted in the database when a user is added
*
* @event core.user_add_modify_notifications_data
* @var array user_row Array of user details submitted to user_add
* @var array cp_data Array of Custom profile fields submitted to user_add
* @var array sql_ary Array of data to be inserted when a user is added
* @var array notifications_data Array of notification data to be inserted when a user is added
* @since 3.2.2-RC1
*/
$vars = array('user_row', 'cp_data', 'sql_ary', 'notifications_data');
extract($phpbb_dispatcher->trigger_event('core.user_add_modify_notifications_data', compact($vars)));The skeleton extension I used created a main_listener.php program in the /event folder where you can hook in code for events like these. To insert a row into the phpbb_users table, I would need to know the user_id that was created. The event passes a user_row array, so it seemed likely the user_id would be inside of it.
Since I was going to access the database, I needed main_listener.php to be able to use phpBB’s database abstraction layer service. So first I went into the /config/services.yml file for the extension and added this service. This was straightforward. Since I didn’t need to use the language service, I removed the language service too. The file became:
services:
phpbbservices.setemailpmnotifications.listener:
class: phpbbservices\setemailpmnotifications\event\main_listener
arguments:
- '@dbal.conn'
tags:
- { name: event.listener }
Next, to hook the database abstraction layer service into main_listener.php. I removed any references to the language service first, then hooked in the database service. The main_listener class looked in part like this:
public static function getSubscribedEvents()
{
return [
'core.user_add_after' => 'user_add_enable_pm_email_notifications'
];
}
/* @var \phpbb\db\driver\factory */
protected $db;
/**
* Constructor
*
* @param \phpbb\language\language $language Language object
*/
public function __construct(\phpbb\db\driver\factory $db)
{
$this->db = $db;
}
The getSubscribedEvents function is where you hook in a custom function to an event, the core.user_add_after event in this case. I told phpBB to look for and execute a function in the program, user_add_enable_pm_email_notifications. Further down in main_listener.php I added a small amount of custom code to do what I wanted done inside this function:
public function user_add_enable_pm_email_notifications($vars)
{
$user_id = $vars['user_id'];
$sql = 'INSERT INTO ' . USER_NOTIFICATIONS_TABLE . "(item_type, item_id, user_id, method, notify)
VALUES ('notification.type.pm', 0, " . (int) $user_id . ", 'notification.method.email', 1)";
$this->db->sql_query($sql);
}
The incoming $vars variable contains a collection of stuff that can be read by my event. It turned out that $vars[‘user_id’] contained the user_id for the next user. Then, based on what I saw in the phpbb_user_notifications table, the SQL INSERT statement became straightforward to write and execute.
I think this demonstrates pretty well how a reasonably experienced web programmer can make a small custom extension to add some missing minor functionality that the phpBB Group did not think was needed.
