PHPFixing
  • Privacy Policy
  • TOS
  • Ask Question
  • Contact Us
  • Home
  • PHP
  • Programming
  • SQL Injection
  • Web3.0
Showing posts with label php-7.3. Show all posts
Showing posts with label php-7.3. Show all posts

Tuesday, August 30, 2022

[FIXED] How to install pear/pecl/xdebug for php using macports

 August 30, 2022     macos-mojave, macports, pear, pecl, php-7.3     No comments   

Issue

I have a PHP setup using macports, on MacOS Mojave. I have just upgraded from 5.6 to 7.3; everything is working fine except that I need xdebug, which requires pecl, which requires pear, and I don't have a working copy of pear any more.

I've found several answers which work using homebrew, but that would mean uninstalling large amounts of stuff and reinstalling them with homebrew, which I'd rather not do if I don't have to.

Various other solutions mentioned in other posts don't work any more because http://pear.php.net/ is down indefinitely. I can find their github site but I can't quite see what to do from there, since their INSTALL file has no instructions for mac.

Any ideas?


Solution

If php 7.2 is sufficient, MacPorts has a port for php72-xdebug. You can install it with

sudo port install php72-xdebug

If you really want 7.3 support, you might ping the maintainer for those packages. There are php73-xxx versions of a number of ports. He hasn't gotten to xdebug at the moment.

More generally, use MacPorts search facility to check for packages you are interested in. For example, enter the following command in Terminal:

port search xdebug

A similar search can be performed on the website, on the Available Ports page:

https://www.macports.org/ports.php



Answered By - Craig
Answer Checked By - Katrina (PHPFixing Volunteer)
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

Tuesday, August 23, 2022

[FIXED] How to override di.xml of core module in custom module Magento 2

 August 23, 2022     magento2, php-7.3     No comments   

Issue

I want to remove some portion from di.xml of vendor module. Below example of some portion that to be removed.

<type name="Magento\Braintree\Block\GooglePay\Shortcut\Button">
        <arguments>
            <argument name="data" xsi:type="array">
                <item name="template" xsi:type="string">Magento_Braintree::googlepay/shortcut.phtml</item>
                <item name="alias" xsi:type="string">braintree.googlepay.mini-cart</item>
                <item name="button_id" xsi:type="string">braintree-googlepay-mini-cart</item>
            </argument>
            <argument name="payment" xsi:type="object">BraintreeGooglePay</argument>
        </arguments>
    </type>

How can I remove the it using override of di.xml in custom module.


Solution

Thanks for sharing the possible options.

The solution that did work for me is to make the item inside argument tag to null. In my scenario, I do not want this item in dependency injection. That works for me.

Below code added in custom module etc/frontend/di.xml

<type name="Magento\Braintree\Block\GooglePay\Shortcut\Button">
     <arguments>
        <argument name="data" xsi:type="array">
           <item name="template" xsi:type="null" />
           <item name="alias" xsi:type="null" />
           <item name="button_id" xsi:type="null" />
        </argument>
        <argument name="payment" xsi:type="object">BraintreeGooglePay</argument>
     </arguments>
</type>


Answered By - Rahul Hedaoo
Answer Checked By - Candace Johnson (PHPFixing Volunteer)
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

Monday, February 14, 2022

[FIXED] Composer installing incompatible package

 February 14, 2022     composer-php, package, php, php-7.3     No comments   

Issue

I have a composer.json file that includes the following:

"require": {
    "php": "~7.3.0",
    "ext-imagick": "*",
    "ext-apcu": "*",
    "ext-json": "*",
    "ext-blackfire": "*",
    "doctrine/doctrine-migrations-bundle": "^1.3",

The later use of --ignore-platform-reqs relates to the docker image not having those extensions, but the Heroku environment does.

The latter is requiring a package, which requires another package.

$ composer why ocramius/package-versions
doctrine/orm            v2.7.2  requires  ocramius/package-versions (^1.2)
ocramius/proxy-manager  2.8.0   requires  ocramius/package-versions (^1.8.0)

$ composer why ocramius/proxy-manager
doctrine/migrations  v1.8.1  requires  ocramius/proxy-manager (^1.0|^2.0)

This is installing code that uses PHP 7.4's property type declarations. This throws a big ugly error in PHP 7.3.

$ php -d memory_limit=-1 composer.phar update --ignore-platform-reqs
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 195 installs, 0 updates, 0 removals
  - Installing ocramius/package-versions (1.8.0): Loading from cache

Parse error: syntax error, unexpected 'string' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in 
             /var/www/project/vendor/ocramius/package-versions/src/PackageVersions/Installer.php
             on line 33

Why am I always getting this version of ocramius/package-versions and how to do I prevent this error (and that package version) from happening?


Solution

The solution for me was to remove --ignore-platform-reqs. For any forward-leaning packages (any Ocramius package, for instance), this will either fail hard like this did, or you'll have several strange bugs you can't seem to track down the cause of.

What --ignore-platform-reqs does is it switches off the checks Composer makes to ensure that only packages compatible with the environment works. In this case, the offending package had a recent update to use PHP 7.4, and happened to use the new property type declarations in the Composer installer.

I had been battling several other weirdnesses (like the Doctrine's Entity Manager failing randomly, another Ocramius-related package), which all went away by removing the flag when I ran Composer. Whatever the reason I needed it years ago, I no longer do.

If you feel you need it, check out config.platform which seems to allow you to lie to Composer, or work to remove needing that flag altogether (why-ever you think you need it, get over it if possible).

Lets you fake platform packages (PHP and extensions) so that you can emulate a production env or define your target platform in the config. Example: {"php": "7.0.3", "ext-something": "4.0.3"}.

https://getcomposer.org/doc/06-config.md#platform



Answered By - Jared Farrish
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg

Monday, January 10, 2022

[FIXED] unserialize() Please specify classes allowed for unserialization in 2nd argument

 January 10, 2022     php, php-7.3, serialization, symfony     No comments   

Issue

In my Symfony application I have a User entity which is serialized. In the unserialize() method, I did this:

    public function unserialize($serialized)
    {
        [
            $this->id,
            $this->email,
            $this->password,
            $this->enabled
        ] = unserialize($serialized);
    }

But PhpStorm underlines in red unserialize($serialized) with the following message:

Please specify classes allowed for unserialization in 2nd argument.

I don't know what I'm supposed to use as a second argument. After some research, I saw that we could put this:

unserialize($serializeObj, ["allowed_classes" => true]);

But I also found this:

unserialize(
    $serializedData,
    ['allowed_classes' => ['Class1', 'Class2']]
);

I'm a little confused, I don't know what I should put in my case so that PhpStorm doesn't complain about this.


Solution

If you are actually serializing an array, and not a class instance, you just need to pass false as allowed classes.

 public function unserialize($serialized)
{
        [
            $this->id,
            $this->email,
            $this->password,
            $this->enabled
        ] = unserialize($serialized, ['allowed_classes' => false]);
}

If you are serializing the whole entity, you need to pass the class you expect to be instantiated from the unserialization

So let's assume the class is App\Entity\User,

public function unserialize($serialized) {

    $new = unserialize($serialized, ['allowed_classes' => [ User::class ]]);
    $this->id       = $new->getId();
    $this->$email   = $new->getEmail();
    $this->password = $new->getPassword();
    $this->enabled  = $new->isEnabled();

}

I'm assuming you have have getter methods in the entity for the sake of simplicity.



Answered By - yivi
Read More
  • Share This:  
  •  Facebook
  •  Twitter
  •  Stumble
  •  Digg
Older Posts Home
View mobile version

Total Pageviews

Featured Post

Why Learn PHP Programming

Why Learn PHP Programming A widely-used open source scripting language PHP is one of the most popular programming languages in the world. It...

Subscribe To

Posts
Atom
Posts
All Comments
Atom
All Comments

Copyright © PHPFixing