FoF Terms, ask your users to accept TOS and Privacy Policy

FriendsOfFlarum

Terms by FriendsOfFlarum

This extension allows you to define a list of terms the user must agree to before using the forum.

It was made with the new General Data Protection Regulation in mind but please consult with your legal team to see whether it fits your requirements.

Compatibility

This extension might not be compatible with other extensions that make change to the sign up modal as well. If an extension is not listed below, please try it on a test forum first and let us know if it works.

Works with:

Sijad's reCAPTCHA (tested with 0.0.2)

Does not work with:

ReFlar User Management version 0.1.* (should be compatible again in future version 0.2) see ReFlar/user-management20 for more details

FriendsOfFlarum Masquerade when the "Force user to complete profile" option is enabled (there's a deadlock between the need to complete the profile and the need to accept the terms)

Installation

composer require fof/terms

Updating

composer require fof/terms
php flarum migrate
php flarum cache:clear

Updating from Flagrow

This extension replaces Flagrow Terms.

To upgrade from the old extension to the new one:

Backup your data! You should backup the database. You can also download Terms' data as JSON, see documentation below.
Disable the Terms extension in the admin panel.
Run:

composer require fof/terms

Composer should let you know that flagrow/terms has been automatically removed.

Enable the new extension in the admin panel.
Your existing data will be migrated to FoF Terms automatically.

Configuration

You can define a list of "policies" the users must agree to. A policy has a name and url.

You can define an "update message" that will be shown to users who have not yet agreed to the latest version of the policy or not agreed to the policy at all (this includes users registered before the policy extension was enabled).

You can define an "updated at" time that will ask all users who accepted prior to that date to accept again.

If users don't accept the terms, they can't register. Additionally, if they already have an account, they can login but their account is locked until they accept the latest version of the terms (similar to how the suspend extension blocks users).

You can customize who can skip the modal without accepting the new terms immediately via the permissions tab (by default admins only). You might want to give this permission to bot accounts for example as they will also be blocked from the API if there's a terms update.

Admins can see the date at which a user accepted the terms by going to their profile page and selecting the terms button in the dropdown menu. You can customize who can see those dates in the permissions.

Data Export

In case you want to export the data (for your GDPR logs for example), a JSON and CSV export is available.

The link can be found in the Policy edit form of the admin panel.

If you want to automate the export, the available options are documented on the wiki.

Turkish Extensions Experience Pack for Flarum

English

Always up-to-date, always improving Flarum language experience!

We are now delivering free language updates through the this package. This means we can continuously improve your local language and automatically send these updates to your site. By installing the Extensions Experience Pack extension, the Flarum text in your language will always be up-to-date.

Interested in helping make Flarum text in your local language better? You can easily provide suggestions on text improvements using the GitHub. Just visit "Issues" page on our extension page.

Türkçe

Her zaman güncel ve her zaman gelişen Flarum dil deneyimi!

Şimdi bu paket aracılığıyla ücretsiz dil güncellemeleri sunuyoruz. Bu, yerel dilinizi sürekli olarak iyileştirebileceğimiz ve bu güncelleştirmeleri otomatik olarak sitenize gönderebileceğimiz anlamına geliyor. Uzantılar Deneyim Paketi uzantısı yüklendikten sonra dilinizdeki Flarum metni her zaman güncel kalır.

Flarum metninin yerel dilinizde daha iyi olmasına yardımcı olmak ister misiniz? GitHub’ı kullanarak metin geliştirmeleri hakkında kolayca önerilerde bulunabilirsiniz. Uzantı sayfamızdaki “Sorunlar” sayfasını ziyaret etmeniz yeterlidir.

Most used extensions translated by me and @melih to Turkish.

Here's the list:
Click to view supported extensions and translation percentages

Upload by FriendsOfFlarum
Formatting by FriendsOfFlarum
User Directory by FriendsOfFlarum
Links by FriendsOfFlarum
User Bio by FriendsOfFlarum
Polls by FriendsOfFlarum
Night Mode by FriendsOfFlarum
Follow Tags by FriendsOfFlarum
Best Answer by FriendsOfFlarum
Analytics by FriendsOfFlarum
Split by FriendsOfFlarum
Pages by FriendsOfFlarum
Reactions by FriendsOfFlarum
OAuth by FriendsOfFlarum
Moderator Notes by FriendsOfFlarum
Merge Discussions by FriendsOfFlarum
Impersonate by FriendsOfFlarum
Sitemap by FriendsOfFlarum
Flarum SEO by JasperVriends
Byobu by FriendsOfFlarum
Ban IPs by FriendsOfFlarum
Pretty Mail by FriendsOfFlarum
Ignore Users by FriendsOfFlarum
Discussions Views by MichaelBelgium
reCAPTCHA by FriendsOfFlarum
Spamblock by FriendsOfFlarum
Terms by FriendsOfFlarum
StopForumSpam by FriendsOfFlarum
Gamification by FriendsOfFlarum

Install

composer require tolgaaaltas/flarum-ext-turkish:*

Please be sure the update language pack.
composer update tolgaaaltas/flarum-ext-turkish

This is only extensions pack, not included core.

You may also be interested in this extension: 🇹🇷 Turkish Core Experience Pack

Find us on GitHub
Also on Packagist
Flagrow (Bazaar extension)

FAQ

Q1: Does this extension completely translate my Flarum to Turkish?
A1: No, as i wrote this extensions it only translates third party extensions. You need an another translate package for core. Check out these translation packages;
for beta 10: 🇹🇷 Turkish Core Experience Pack

baicai

FriendsOfFlarum
There may be a bug.
After the user “clicks here to view and agree to the new Terms of Service”, no pop-up window will appear, and the web page will be stuck, resulting in the mouse not being able to click on any content, and in the case of mobile, the top navigation bar will become blank.
Below is the error message from the console:

mount-redraw.js:15 TypeError: Cannot read properties of undefined (reading '1') at AcceptPoliciesModal.js:28:40 at Array.filter (<anonymous>) at e.body (AcceptPoliciesModal.js:27:43) at e.content (AcceptPoliciesModal.js:22:34) at n.view (Modal.tsx:164:19) at Function.a (render.js:30:16) at render.js:155:45 at render.js:160:3 at c (render.js:66:8) at l (render.js:50:5) a @ mount-redraw.js:15 (匿名) @ mount-redraw.js:25 requestAnimationFrame u @ mount-redraw.js:23 t.4615.t.exports.O.handleEvent @ render.js:890 显示简略信息

Ghost_chu

Nice job!

Ralkage

Beat me too it ?

Excellent job, @clarkwinkelmann!!

Ghost_chu

My Google reCAPTCHA has been replaced by custom text....
Please fix it,Thanks

jordanjay29

Ghost_chu as a result of this extension or what? Please post a screenshot or describe the behavior in more detail.

Ghost_chu

jordanjay29 for sure.I install the recaptcha ext,The register page under password input box,There should have a reCAPTCHA,But when I after install flagrow/term,The reCAPTCHA has been replaced by THIS ext the optional legal text box.
This make my user can verifyed the reCAPTCHA to register account.

This happed on OFFICAL FLARUM too.

clarkwinkelmann

To everybody having a look at this extension: it has not been tested for compatibility with other third-party extensions.

Given how little extensibility Flarum offers in modals (and here in the signup modal) it's quite possible that two extensions modifying it will collide and break.

Please report any incompatibility in the GitHub issues. Don't forger the output of php flarum info or composer show so we know the exact versions installed. You can disable other extensions to pinpoint which one isn't compatible. If the other extension if pretty popular or the fix is simple I'll try to get them working together. Otherwise I'll build a list in the README to indicate incompatibilities.

Also a heads up: if there's any issue with a Flarum fork, Flagrow most likely won't fix the issue. All our new extensions are currently made and tested for the official beta 7 and 7.1. Thanks for understanding ?

EDIT: Ghost_chu can you open an issue on GitHub with the link to the recaptcha extension concerned ?

clarkwinkelmann

First bugfix release already. 0.1.1 fixes an issue if you have an older version of nesbot/carbon installed.

Get the fix with composer update flagrow/terms.

composer update nesbot/carbon would also fix the issue.

ChadJessen

Awesome!

clarkwinkelmann

Just released 0.1.2 which adds Spanish translation.

Update with

composer update flagrow/terms
php flarum cache:clear

Pollux

@clarkwinkelmann

I have several problems installing this extension.

First of all: the tables created by this extension were of type InnoDB whereas all the other tables of Flarum are MyISAM. Is this supposed to be that way? Additionally I got errors I unfortunately didn't save and don't remember anymore.

Then I changed the default storage engine to MyISAM but with limited success. Only one of the tables was created, so I created the other table myself according to the instructions in the migrations, but it seems I made mistakes there, as I could activate the extension but adding a policy resulted in a strange error:

Column not found: 1054 Unknown column 'updated_at' in 'field list'' in ...

When I renamed terms_updated_at to updated_at, I got the error:

Column not found: 1054 Unknown column 'term_updated_at' in 'field list'' in ...

So I decided to go back to start: removed the extension via ssh, removed the tables flagrow_terms_policies and flagrow_terms_policy_user, removed the columns flagrow-terms.hide-updated-at and flagrow-terms.signup-legal-text in the settings table (only those had been added during my previous trials), and changed the default storage engine back to InnoDB.

But now my database seems to refuse to create the tables flagrow_terms_policies and flagrow_terms_policy_user when I reinstall your extension. Accordingly, the admin panel throws an error:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'flarum.flagrow_terms_policies' doesn't exist (SQL: select `flagrow_terms_policies`.*, `flagrow_terms_policy_user`.`user_id` as `pivot_user_id`, `flagrow_terms_policy_user`.`policy_id` as `pivot_policy_id`, `flagrow_terms_policy_user`.`accepted_at` as `pivot_accepted_at` from `flagrow_terms_policies` inner join `flagrow_terms_policy_user` on `flagrow_terms_policies`.`id` = `flagrow_terms_policy_user`.`policy_id` where `flagrow_terms_policy_user`.`user_id` = 1)

This happens even before I have the chance to activate the extension, so I assume that the migration should take place during ssh composer require flagrow/termsalready. But there is no error message:

composer require flagrow/terms
Using version ^0.1.2 for flagrow/terms
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing flagrow/terms (0.1.2): Loading from cache
Package http-interop/http-middleware is abandoned, you should avoid using it. Use http-interop/http-server-middleware instead.
Writing lock file
Generating autoload files

In the database the tables flagrow_terms_policies and flagrow_terms_policy_user indeed don't exist after installing terms.

Do you have any idea?

luceos

Pollux inside the migrations table delete any entries related to the extension, otherwise the migrations won't re-run.

Pollux

luceos This didn't help.

Reinstalling terms doesn't perform any changes to the database anymore. It doesn't create any of the new tables nor does it create new entries in the migrations or settings table..

luceos

Pollux re-installing does not run migrations, enabling does. So you would have to re-enable it if you uninstalled it when enabled after removing the migrations entries and tables related to the extension (does this even make sense ? )

Pollux

luceos does this even make sense ?

Halfway ?

But I'm one step further. My problem was, that I could not access the Admin panel because of the error described above (Table 'flarum.flagrow_terms_policies' doesn't exist). I therefore assumed, that the migration took place during installation and not after enabling it.

So how could the Admin panel complain if the extension was a fresh install?

The answer: settings.extensions_enabled still contained your extension because obviously I deinstalled it while still enabled. So after re-installing it it was automatically viewed as enabled without running the migration.

So, now I have terms installed and the Admin panel doesn't crash immediately anymore. Now I try to enable the extension:

exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint' in /path/to/flarum/vendor/illuminate/database/Connection.php:390\nStack trace:\n#0 /path/to/flarum/vendor/illuminate/database/Connection.php(390): PDOStatement->execute(Array)\n#1 /path/to/flarum/vendor/illuminate/database/Connection.php(655): Illuminate\\Database\\Connection->Illuminate\\Database\\{closure}(Object(Illuminate\\Database\\MySqlConnection), 'alter table `fl...', Array) ...

Like before, flagrow_terms_policies and flagrow_terms_policy_user are created as InnoDB tables. I don't know whether that's the reason why the foreign key constraint can't be added.

Shall I try the path of changing the default storage engine to MyISAM again?

Pollux

I just queried my database: SHOW ENGINE INNODB STATUS

The result:

------------------------
LATEST FOREIGN KEY ERROR
------------------------
2018-05-09 13:05:35 0x7000044e1000 Error in foreign key constraint of table flarum/#sql-11ba_5c:
foreign key (`user_id`) references `users` (`id`) on delete cascade:
Cannot resolve table name close to:
(`id`) on delete cascade

Does that help?

Edit: As I understand the engine should be the same in both tables. But users is MyISAM and flagrow_terms_policy_user is InnoDB. I guess that's causing the error.

luceos

Pollux once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations. Now that you didn't the migrations fail. You will have to remove the foreign key constraints from your database as well before trying to re-enable the extension.

This is one of the reasons why doing these things manually often is a bad idea ?

clarkwinkelmann

Wow there's a lot discussed there.

Pollux Edit: As I understand the engine should be the same in both tables. But users is MyISAM and flagrow_terms_policy_user is InnoDB. I guess that's causing the error.

Only the posts table should be MyISAM in a normal Flarum install. Indeed the Terms migrations expect users to be InnoDB, otherwise MySQL won't be able to create a foreign key (foreign keys are an InnoDB thing I believe).

You could skip adding that foreign key if creating the tables manually, this won't cause any serious issue. There might just be dead records in the table flagrow_terms_policiy_user after a while if you delete users.

luceos The down method should have deleted the foreign key constraint, which is possible using dropForeign

When adding a column and a foreign key as part of a migration, dropForeign should indeed be used in the down part. But I've never used it when dropping a table altogether. Dropping a table drops the foreign keys automatically. If users had a foreign key contraint referencing the table we're deleting that would be another story, we'd need to first drop all foreign contraints targeting the table we're deleting. But it's rare as you usually run migrations down in a logicial order (inverse of creation).

Pollux This foreign key needs to be removed, the column can't simply be dropped.

Correct me if I'm wrong, but as I pointed above we're deleting the whole table so both column and keys automatically go away normally.

Pollux

luceos This is one of the reasons why doing these things manually often is a bad idea ?

That's what I'm learning right now. ? But that's OK for me, I like learning. ?

luceos once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations.

So how do I delete the foreign key constraints in MySQL? The only hack I found was making a copy of the users table without constraints and replace users with that otherwise identical copy.

But this didn't solve my problem. I still get the General error: 1215 Cannot add foreign key constraint

Are you sure, that the different storage engines aren't a problem? Or should I try to change the default storage engine to MyISAM? What storage engines are supposed to be used in the users table and in those of your extension?

Pollux

clarkwinkelmann Only the posts table should be MyISAM in a normal Flarum install.

That's interesting. In my two installs (one locally and one on shared hosting) both via the standard composer way, all tables are MyISAM except the two new tables of the terms extension.

clarkwinkelmann Indeed the Terms migrations expect users to be InnoDB, otherwise MySQL won't be able to create a foreign key (foreign keys are an InnoDB thing I believe).

That's what I have learnt in the last hours. So mixing both storage engines doesn't seem a problem.

And if all my other tables are MyISAM, that means that foreign key constraints aren't used within the rest of Flarum?

clarkwinkelmann Dropping a table drops the foreign keys automatically.

So the foreign keys are somehow attached to the child table? In the case of:

$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');

... the foreign keys are attached to the flagrow_terms_policy_user table and not the users table?

But why did you, Luceos, write:

luceos once you deleted the tables manually, you should also have deleted the foreign key constraints added by the migrations. Now that you didn't the migrations fail.

Are there different ways of deleting a table? if I use the drop table button in phpMyAdmin to drop flagrow_terms_policy_user, doesn't that delete the foreign key constraints as well? Are there any chances that foreign key constraints survive such a drop?

So coming backt to the InnoDB status error:

------------------------
LATEST FOREIGN KEY ERROR
------------------------
2018-05-09 13:05:35 0x7000044e1000 Error in foreign key constraint of table flarum/#sql-11ba_5c:
foreign key (`user_id`) references `users` (`id`) on delete cascade:
Cannot resolve table name close to:
(`id`) on delete cascade

What could that be?

The table name close to: (`id`) on delete cascade, shouldn't that be the users table? And if so, why couldn't the table name be resolved?

I will investigate further...

Ralkage

Pollux You could of also dropped the column VIA ALTER TABLE statement.

ALTER TABLE "table_name"
DROP "column_name";

Given that the column is not part of core (which it looks to be).

@luceos any particular reason why ->onDelete('cascade');is used in up portion of the migration and not down?

luceos

Ralkage onDelete('cascade') is a Laravel method that simply tells MySQL to delete related records whenever the foreign record is deleted. The down method should have deleted the foreign key constraint, which is possible using dropForeign.

Pollux

Ralkage Given that the column is not part of core (which it looks to be).

That's the part of the migration we are talking about:

2018_04_30_create_flagrow_terms_policy_user.php

$table->foreign('policy_id')->references('id')->on('flagrow_terms_policies')->onDelete('cascade');
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');

So the first foreign key (policy_id) refers to the id column in the flagrow_terms_policies table (parent). That's not so important as the flagrow_terms_policiestable gets deleted as well. The second foreign key (user_id) however refers to the id column in the userstable. This foreign key needs to be removed, the column can't simply be dropped.

Do I understand that correctly?

Ralkage any particular reason why ->onDelete('cascade'); is used in up portion of the migration and not down?

Delete actions are tied to a foreign key constraint, these are defined on up. What do you want to do on down? On down I would rather expect the removal of the foreign key constraints added by the migration.

Edit: I just saw, that @luceos already explained my last point.