Drupal9: installing problem PHP-encryption library - encryption

for encryption data i wants to use in Drupal9 the PHP-encryption library width "REAL AES" Module. But Drupal can not find the PHP-encryption library while enaple the "REAL AES" module.
It is very new to use PHP-encryption in Drupal9, so i think there can be a bug in code or in readme.txt of Installationprozess.
So my main question is: In Which folder do i have to install PHP-encryption-Code?
I installed by the hint of REAME.txt "composer require defuse/php-encryption". But it was unclear in which folder:
In Root of Server? or
In Drupal-Folder sites/all/libraries/php-encryption or
In Drupal-Folder of REal AES Module: modules/real_aes/defuse/
Question: Drupal9 works with composer. Do I have to activate the PHP-encryption library especially? for ex. in main composer.json ?
Thank you for your help, because I m new in Drupal9.
After activating the REAl AEs Module in Drupal9, the module wants to use the library. That does not work, so it shows the errormessage
Please install the Defuse PHP-encryption library via Composer. See README.txt
I use this Drupalmodule:
https://www.drupal.org/project/real_aes
PHP-encryption library:
https://github.com/defuse/php-encryption
So now im looking in the code of php-encryption library und found the Problem in checking the existens of a Class which causes the problem.
so this becomes false instead of true:
if (class_exists('\Defuse\Crypto\Crypto'))
in https://www.drupal.org/files/issues/2613682-3.patch
So the result is the text above "Please install the Defuse PHP-encryption library via Composer"...
but the class Crypto is in folder /defuse/src/Crypto.php
<?php
namespace Defuse\Crypto;
use Defuse\Crypto\Exception as Ex;
class Crypto
{

Now it works:
I had to install php-encryption-library with composer in folder of the module!

Related

Drupal 9: dd(), ddm() or drupal_dump() missing

I've installed D9 plus devel and created a custom theme (with all the necessary files, works nicely) and enabled all the necessary dev-centric settings, but it seems that the necessary functions like dd() or drupal_dump() are not found. I've already checked that everything related to the devel module (devel, devel generate, devel web profiler) is enabled in my Drupal.
Any help appreciated!
drupal_dump(), alias dd(), is not provided by devel, but by another module named twig_tweak. It requires Symfony's VarDumper component to work. You can install them using composer :
composer require --dev symfony/var-dumper
composer require drupal/twig_tweak
drush en twig_tweak
ddm() doesn't print anything to the screen but outputs a variable to a file named drupal_debug.txt in the site's temp directory.
More on devel functions here.
Long story
In drupal 7.x and up to version 8.6.0, dd() was indeed provided by the devel module, but it was an alias for drupal_debug() (d7) and DevelDumperManager::debug() (d8), but it has been deprecated and replaced by ddm() since 8.6.0, because Symfony's VarDumper component already has a function named dd().
Now to add further confusion, twig_tweak is using the alias dd() for drupal_dump() (source).
Even if both functions end up calling Symfony's VarDumper::dump(), Symfony's dd means "dump and die" and is meant to immediately ends the execution of the script after dumping the variables, whereas twig_tweak's drupal_dump/dd does not.
The exact same thing happens in Laravel : it uses Symfony's VarDumper and overrides its dd function with a function that doesn't behave the same, instead of using a different name.

Why VS2019 marks my extension as deprecated

I don't use VSIX for integration (supports old VS and SSMS). Installer puts all dlls to "program files" and pkgdef and manifest to specific folders. Currently VS2019 shows message that my extension use "deprecated API".
Image with message from learn.microsoft.com but it's the same.
I done this steps:
I created asyncPackage (now empty).
Added with
Microsoft.VisualStudio.Component.CoreEditor to vsixmanifest
Generated catalog.json and manifest.json using code from here
My package looks so (constructor is empty now)
[PackageRegistration(UseManagedResourcesOnly = true, AllowsBackgroundLoading = true)]
[InstalledProductRegistration("#110", "#112", "7.1.7", IconResourceID = 115)]
[ProvideMenuResource("MyMenus.ctmenu", 1)]
[ProvideAutoLoad(GuidList.ShellInitialized, PackageAutoLoadFlags.BackgroundLoad)]
[ProvideAutoLoad(VSConstants.UICONTEXT.NoSolution_string, PackageAutoLoadFlags.BackgroundLoad)]
[System.Runtime.InteropServices.Guid(GuidList.guidMyPkgString)]
public sealed class MyPackage : AsyncPackage {
But VisualStudio shows message about deprecated API again and again. What I missed? What VS checks during package loading?
Edit: I created AsyncPackage, added attributes, updated integration files to VsixV3. Why VS loads extension synchronously?
For whom this can help to resolve the same issue.
As I mentioned above we don't use VSIX. And all files are coping by installer. The issue was that this was missed:
[$RootKey$\Packages\{YOUR PACKAGE GUID}]
#="YOUR PACKAGE NAME"
"AllowsBackgroundLoad"=dword:00000001
I've found it during checking all packages in private registry privateregistry.bin
Also don't forget about UI Context if you are using it:
[$RootKey$\AutoLoadPackages\$UICONTEXT_GUID}]
"$YOUR_PACKAGE_GUID”= dword:00000002
Thanks to MS git

Symfony ICU Issue, routes using locale different than EN will fail

After installing Yosemite and a new version of MAMP
and when I'm trying to execute
domain/app_dev.php/es/venues/3/show
This route is rendering a form containing a language type field, so it's requiring ICU.
being 'es' the locale i get errors. If I changed it to 'en' there's no problem.
The errors are:
[1/2] ResourceBundleNotFoundException: The resource bundle
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/root.php"
does not exist.
[2/2] Couldn't read the indices [Languages] from
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/es.res".
The indices also couldn't be found in the fallback locale(s)
"root.res".
My symfony version is 2.5, I'm running the MAMP PHP 5.5.10.
I updated dependencies via composer, including "symfony/intl": "*",
I have followed several webs in order to install icu and intl via pecl. But still get the error. I don't know how to check if the installations or the configs are ok. Maybe you can let me know how to test both via terminal and let you know what is the result...
This is because you are trying to get resources only for language es. But now (from the moment of importing to Symfony icu data) you need to get language resources via language and country codes es_ES.
You may not be able to just simply activate intl.so after the Yosemite update. I solved the issue installing intl.so following an excellent article by Danilo Braband http://dab.io/posts/getting-started-with-symfony-on-yosemite.html
Solved updgrading to Symfony 2.5.6

QPluginLoader can't find module

I have created a plugin for my application. If I don't use the GDAL library in my code, my application can use this plugin (QPlugin loads it) and it works fine. But if I use classes from the GDAL library QPluginLoader can't load it and the errorstring() method returns ../serverplugin.dll Can't find module.
There are two exported symbols qt_plugin_instance and qt_plugin_query_verification_data in the plugin DLL (I found them with Dependency walker). QPluginLoader uses the QLibrary class internally to interface with the C symbols exported to the DLL. If I don't use GDAL I have only two exported symbols in all plugins at the beginning. When I use GDAL these two symbols are moved at the end of a big list of exported symbols. Maybe these two exported symbols should be at the beginning.
What am I doing wrong?
I had the same problem with QPluginLoader. In few words how I solved it: I create plugin library, let's say lib1.dll which use some stuff from lib2.dll. In my application I try to load lib1 via QPluginLoader.
QPluginLoader loader( adaptersDir.absoluteFilePath(fileName) );
AdapterInterface* adapterIface = qobject_cast<AdapterInterface*>(loader.instance());
In this case loader.instance() returns 0. Solution was to copy lib2.dll into application folder because an application use it for proper load plugin lib1.
QT_BEGIN_NAMESPACE
#define Plugin_iid "Plugin"
Q_DECLARE_INTERFACE(PluginInterface,Plugin_iid)
QT_END_NAMESPACE
Q_PLUGIN_METADATA(IID "PluginInterface" FILE "Plugin.json")
Q_INTERFACES(PluginInterface)

Version information on Xserver modules

I am trying to find a tool that will extract the module version information (a part of the module record) fron an Xserver module. For example, in the Xorg logs I can see the following information for the librecord module in my Xorg.0.log file...
[ 39.892] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 39.905] (II) Module record: vendor="X.Org Foundation"
[ 39.905] compiled for 1.9.0, module version = 1.13.0
[ 39.905] Module class: X.Org Server Extension
[ 39.905] ABI class: X.Org Server Extension, version 4.0
Is there a tools that would allow me to easily extract the aforementioned information. Sometimes you can use modinfo on the module and that will have version information, but that does not always work. The only consistent way I know of now is to parse the xorg log file. Thanks.
Yes, there is and you can also try to write a small one.
http://gitorious.org/xdriverprobe
The problem is that xdriverprobe won't compile on newer servers since I didn't update it to the newest ABIs. Also, xdriverprobe is only used for video drivers, but it can be adapted to be used on other modules. The main source code file (xdriverprobe.c) has less than 500 lines, so you can easily learn by reading it.
It works in Ubuntu 11.10... ./xdriverprobe -o moduledata gives the information you want.
Look at its source code. It does:
dlopen() the module
find a symbol called modulenameModuleData (if your module is called modulename)
that symbol is a XF86ModuleData* See /usr/include/xorg/xf86Module.h
check its member named vers
Spend a few hours and you'll be able to write a very tiny code that does what you want.
More information: http://www.xfree86.org/current/DESIGN17.html#65 (very old document, but most of what's written there is still true today). If you're not happy with that document, you have to read the Xorg source code.
Happy hacking!

Resources