Roland Häder pinned item friendica

Cunnilingus and Fellatio, a dying "specicies"?

According to a statistics done by German # only 51% of all German males are into giving oral sex (# for straight and # for gay/bisexual accumulated) while 56% are into receiving (# ) it. While for females it is even a little lesser, 48% are into receiving it while 45% are into giving it. As it seems, also lesbians are counted in here, but are a minor compared to straight females.

The actual graphs and tables can be found here: So far I can tell that there is no "disgusting" or "unhealthy" thing on giving Cunnilingus (in English, licking # ) simply because I have done it a lot on many different women and so far no tongue or throat # has happened to me. :-p And yes, beside that, there is no "fish shop" down there for me. :-)

I like to ask the whole # about this matter. Is that true with you? Disclaimer: Do not come up with some religious-nonsense or other hatred/disapproving/other nonsense here. I'm asking for a Yes or a No and if so, please more details (being passive/active).

Roland Häder pinned item friendica

Any listening group/forum out there?

I wonder if there is any !listening group/forum out there? Because the old one seems to be closed down. Please re-share if you don't know!

Back with updated instance but wrong UTF?

I have successfully updated my instance to latest code and migrated to new config file. But as you can see, the UTF-8 is broken. What can I set here to fix it? The database says "utf8mb4_general_ci".
Can you check in src\Database\DBA.php what charset is actually used for the connection?
Tomorrow more, already 04:33 a.m. here. :-/
Sorry, busy and hot day today. Will attempt it this evening. :)
As configured $charset has value utf8mb4.
Do I have to run queries like this to fix it: UPDATE `item-content` SET `body`= REPLACE(`body`,'ö','?');?
Found a better one:

`body` =

Source: stackoverflow
Careful with already converted data, like I had with contact table where all converted uni-code characters had been converted to question marks. I then had to re-fetch all these contacts over the "Advanced" tab, still there are some pending. GNUSocial allows me to refresh contacts through scripts. Maybe a good idea for Friendica as well?
While clicking on "re-fetch contact data" in the "Advanced" tab, I get these E_NOTICE with OStatus contacts:

Notice: Undefined index: body in /var/www/../src/Protocol/OStatus.php on line 1163
Notice: Undefined index: title in /var/www/../src/Protocol/OStatus.php on line 1916
Notice: Undefined index: guid in /var/www/../src/Protocol/OStatus.php on line 1925
Notice: Undefined index: tag in /var/www/../src/Model/Item.php on line 2787
Notice: Undefined index: tag in /var/www/../src/Model/Item.php on line 2796
Notice: Undefined index: attach in /var/www/../src/Protocol/OStatus.php on line 1372

Will prepare a PR for them.
Found a parser error in addons:
PHP Parse error: syntax error, unexpected '}', expecting end of file in ./addons/pumpio/pumpio.php on line 228

Parse error: syntax error, unexpected '}', expecting end of file in ./addons/pumpio/pumpio.php on line 228

Errors parsing ./addons/pumpio/pumpio.php
Branch pumpio/import-curly-braces created, PR is on it's way.
More errors while deleting an item:
Notice: Undefined index: remote in /var/www/../include/items.php on line 357
Notice: Undefined index: confirm in /var/www/../include/items.php on line 368
Notice: Undefined index: canceled in /var/www/../include/items.php on line 391

Yes, some of you may say that I can switch off E_NOTICE but that is causing more trouble than solving it. The best practice in my oppinion is, to get to the root of the cause and not supress errors and warnings.

Only a #fixed #bug is a good bug. :-)
Again, some "downtime" (errors) due to updating my develop branch to latest upstream (= main repository) changes.

Latest develop fails to run SQL update

@Friendica Developers I have an error while the db update was running, Friendica was sending me an email about it.
The friendica developers released update 1274 recently,
but when I tried to install it, something went terribly wrong.
This needs to be fixed soon and I can't do it alone. Please contact a
friendica developer if you can not help me on your own. My database might be invalid.
The error message is
Errors encountered performing database changes: ALTER IGNORE TABLE `item` DROP INDEX `contactid_allowcid_allowpid_denycid_denygid`, DROP INDEX `uid_authorlink`, ...

On console I get this error:
Error 1296 occurred during database update:
Got error 64 'Temp file write failure' from InnoDB

I'm now back at my old commit so the instance can work again.
Editing a photo causes E_NOTICEs:

Notice: Undefined index: group_allow in /var/www/../mod/photos.php on line 356
Notice: Undefined index: contact_allow in /var/www/../mod/photos.php on line 357
Notice: Undefined index: group_deny in /var/www/../mod/photos.php on line 358
Notice: Undefined index: contact_deny in /var/www/../mod/photos.php on line 359
Another one when I view notifications:
Notice: Undefined index: verb in /var/www/../src/Core/NotificationsManager.php on line 276
Here, $it misses that element.

E_NOTICE in .htconfig.php ?

Hi @Friendica Developers I'm getting this error on my instance (this):

PHP Notice:  Use of undefined constant REGISTER_CLOSED - assumed 'REGISTER_CLOSED' in /var/www/../.htconfig.php on line 38
PHP Stack trace:
PHP   1. {main}() /var/www/../bin/daemon.php:0
PHP   2. include() /var/www/../bin/daemon.php:41

I get this every time I start or stop the daemon (as you can see in backtrace).
Okay, it always starts and stops, just a bit annoying.

Update of develop branch

Dear @Friendica Developers I have now updated to latest develop code and rebased my branch. There have always been a scripts/dbstructure.php around. How do I now update? The offline documentation does not provide any information about this.
And I got this on ./bin/console dbstructure update:

ALTER IGNORE TABLE `gserver` MODIFY `register_policy` tinyint NOT NULL DEFAULT 0 COMMENT '', MODIFY `registered-users` int unsigned NOT NULL DEFAULT 0 COMMENT '', MODIFY `network` char(4) NOT NULL DEFAULT '' COMMENT '', ADD `relay-subscribe` boolean NOT NULL DEFAULT '0' COMMENT 'Has the server subscribed to the relay system', ADD `relay-scope` varchar(10) NOT NULL DEFAULT '' COMMENT 'The scope of messages that the server wants to get', COMMENT = 'Global servers';

Error 1060 occurred during database update:
Duplicate column name 'relay-subscribe'

You may want to split this combined SQL statement into single statements then at least all the other parts will work.
This SQL query was automatically generated by the DBStructure::update process that compares your current database schema with the target Friendica current schema. Basically, the script concluded that your gserver table was missing a column and tried to add it back again. I'm not sure why it doesn't see the current column though. This would be a question for @Michael Vogel, he created the DB update routine.
Have done it here. I have also updated my instance again because of the #bug with user accounts.

Local "connect" not working

I think I found a #bug in #friendica, latest develop code. I have rebased my branch to latest changes and revert all of my is_filled_array() changes to dba::is_result().

So what I did was I created an account for my wife and tried to connect to but all I got was a redirect and no entry in table 'intro'. There is also no entry of her account in 'fcontact'.

So what is wrong?
Ah, validate_url() misses to check $h with is_array(). Please try to cherry-pick my latest commits in branch rhaeder-develop (changed develop branch).
Ah, validate_url() misses to check $h with is_array(). Please try to cherry-pick my latest commits in branch rhaeder-develop (changed develop branch).
Later posts Earlier posts