🇮🇹Italy @aronne

What a mess guys :)
Anyway I think everything should be ok now.
Let me know if it's working for you as well.

Regards,
aronne.

Hi @fabrer,
for you to use proxy when using HTTP Client Manager, all you need to do is just to configure your client in this way:

beh_services.httpbin:
  title: "[Services] Httpbin"
  api_path: "/src/api/httpbin.yml"
  config:
    base_uri: "https://httpbin.org"
    proxy:
      http: 'https://<user>:<password>@<location>:<port>''
      https: 'https://<user>:<password>@<location>:<port>'
      no: ['127.0.0.1', 'localhost']

And that's it, you're good to go. If you have multiple clients sharing the same proxy configurations, you can create a master client and then extend it. You can find a tutorial on how to do it by looking at the module documentation.

I tried it by myself:

Hope it helps.

Kind regards,
aronne

Hi @trickfun,
I just installed the module on a fresh D10 installation and I can't reproduce this bug.

Everything seems to work fine.

Hi @datawench,
thank you for your contribution.
Documentation fixed.

Regards,
aronne

Fixed wrong service name, from acme_services.contents to acme_services_contents

Hi @trickfun,
please install the module by using composer:

composer require 'drupal/http_client_manager:^9.3'

Regards,
aronne

Hi @gorkagr
I just released version 9.3.11 with your fix.

Thanks for your contribution and sorry for the delay.

Regards,
aronne

Hi there,
sorry for the long wait. I'm gonna fix it ASAP.

Did you read what I wrote in comment #7 ✨ Use the name property of Guzzle service description Needs review ?

Hi there,
you can use another name in your service description and then use the "sentAs" property to send it as "pagination.limit"

operations:
  GetProposals:
    httpMethod: GET
    uri: "juno/cosmos/gov/v1beta1/proposals"
    summary: "Gov Last Proposals"
    responseModel: Proposals
    parameters:
      limit:
        location: query
        description: Pagination limit
        type: string
        required: false
        default: '10'
        sentAs: "pagination.limit"

Regards,
aronne

This one is for 3.x

Here is the patch.

aronne → created an issue.

Hi @ovilla,
the HttpConfigRequestForm class converts strings written in JSON format to array and objects.
That's why it works when you use Http Config Requests written by using their original form.
I don't know how BPM.io is building this form but I think it's missing this "little" part

      // ...

      case 'array':
      case 'object':
        $element['#type'] = 'textarea';
        $element['#rows'] = 12;
        $element['#description'] .= '<div class="json-help">' . $this->t('Example') . ': <small><pre>' . $this->getJsonHelp($param) . '</pre></small></div>';
        $element['#attributes']['placeholder'] = $this->t('Enter data in JSON format.');
        $element['#value_callback'] = [$this, 'jsonString'];
        $element['#element_validate'][] = [
          $this,
          'validateJson',
        ];
        break;

        //....

I don't think this problem is caused by HTTP Client Manager module itself since it works fine on this side.

Hi @taraskorpach,
I’m sorry to hear that. I thought linking the issue was enough but maybe you are right.

I’ll try to be more accurate next time.

Kind regards,
aronne

Omg yes, thank you @andreastkdf
I'm gonna upload the new patch now.

Thanks again.
aronne

Hi @redsky,
you should use the Handler Stack as described here: https://www.drupal.org/docs/8/modules/http-client-manager/the-handler-stack →
Use the handler stack to perform your first request and set the cookie you'll later use on your second request.

Regards,
aronne

Hi @kopeboy,
here it is the patch which should do the work you were looking for.
You can now add a "label" property in your guzzle service description and it will be used as label for your parameter in the http config request form.

Regards,
aronne

Uploading the patch.
You can now use tokens for every value of your http service api configuration.

Hi @datawench,
I think it would be nice being able to use tokens for any parameter of the http services api and not just the base_uri. In this way you could put your basic auth settings wherever you want and then make them available as tokens.

I'm gonna work on this solution.

Regards,
aronne

What makes form alters special over other alter hooks? why not a plugin for every hook?

We're getting into well trodden territory, such as proposals to improve the hook system generally, or implementing event dispatch/subscribers and weight/priority systems.

A recent example is #3366083: [META] Hooks via attributes on service methods (hux style).

And you have contrib solutions already which handle hooks/alters generally, such as Hook Event Dispatcher and Hux with priority/ordering systems. Each have their own way of doing dependency injection.

We're going to need a harder sell on why you want this and what makes your proposal unique.

Since nobody else but us seem to be interested in porting this module inside Drupal Core I'd say we can close this issue and leave things as they already are. Good luck with it

Hi @datawench,
you can find the updated documentation here: https://www.drupal.org/docs/contributed-modules/formalter-as-plugin/alte... →

Thank you for your contribution.

Regards,
aronne

fixed formatting

added info about changing form alter priority

Hi @dahousecat,
and thank you for you contribution.
Patch applied on the dev branch.

Hi @datawench
eh... you got a very good point you know? I think forcing a behavior is never the correct solution, since there could always be a case for which that forced behavior would be wrong. But your observation about documenting this solution sounds really good to me.
So yes I'm gonna add it soon.
Thank you again for you contribution.

Regards,
aronne

Patch #7 doesn't work. file composer.json doesn't change in module folder.

No I'm just saying that if you put the patch in the drupal document root, as I think he did, and then you run git apply 3406108-7.patch it won't work.

@aronne I'm not sure I understand. Are you saying that the patch shouldn't apply if you add the appropriate element in the cweagans-style "patches" portion of the root composer.json?

@atawench Adding the patch in the root composer.json is how it should be done properly.

Added info about formParam location

Hi @trickfun,
have you tried using the "body" location instead of "form_params"?

Hi @kopeboy
please consider that Guzzle documentation is out of the scope of this module and HTTP Client Manager is just a wrapper around Guzzle.

Anyway I've updated the documentation hoping it's clear enough now and that it could help people in the future understanding which location parameter should be used.

Thank you again for your contribution,
aronne.

See https://www.drupal.org/project/http_client_manager/issues/3414740  →

@AstonVictor this one should be ported also for the 3.0.x version of the module.

Hi @AstonVictor,
thank you for your work. I'm just unsure about this piece of code:

// Enable prevnext links for node entity type.
$config = \Drupal::configFactory()->getEditable('prevnext.settings');
$config->set('prevnext_enabled_entity_types', ['node' => 'node']);
$config->set('prevnext_enabled_entity_bundles', ['node' => ['prevnext' => 'prevnext']]);
$config->save();

I'm not sure if changing config values during tests is a best practice, but maybe I'm wrong.

Hi @AstonVictor,
Patch applied to both versions of the module.

Thanks man,
aronne

@trickfun composer.json will never change if you run patch #7 in the drupal root instead of the module root.

ok perfect thanks again @AstonVictor.

Yes it would be great @AstonVictor

Hi @AstonVictor,
I merged your MR against 2.0.x
Please open a new MR for the 3.0.x branch as well so that we can close this issue.

Thank you and kind regards,
aronne.

Ok this patch should be the right one.
I've already submitted it on the dev version so please let me know if it works for you as well by doing
composer require 'drupal/http_client_manager:3.x-dev@dev'

Regards,
aronne

Hmm no I have to figure out why composer can’t find the release

I’ll work on it later

Hi guys,
I've just made a fork of that library and here you can find the patch that should fix the problem.

Regards,
aronne

Added info about wildcards

Hi guys,
please feel free to try this patch and let me know if it works for you as well.

/**
 * Class D10TestingFormAlter
 *
 * @FormAlter(
 *   id = "d10_form_alter",
 *   label = @Translation("Altering forms."),
 *   form_id={"*"}
 * )
 *
 * @package Drupal\d10_testing\Plugin\FormAlter
 */

This definition should alter any existing form. I also tried using "user_*" as form_id.

Anyway, let me know.

Regards,
aronne

Hi guys,
Yes this feature request is totally legit.
I’m gonna work on it in the next couple days.
Stay tuned and text you soon

aronne

@AstonVictor the issue status is still in "Needs work".
Did you forget to change it or does it really need more work?

Ok thank you @tyler36,
patch committed on dev branch and is gonna get released soon.

Regards,
aronne

Hi guys,
sorry for the delay.
I'm gonna upload the patch you were asking for.

Hope that's what you were looking for.
I already tested it and it works fine.

Regards,
aronne

@AstonVictor I don't think creating a submodule for taxonomy terms is the right choice to make.
I would rather do a work of refactoring and create a new Annotation Plugin called PrevNext which could be derived for any entity type so that we won't break the DRY principle.

@AstonVictor the MR is outdated and should get rebased locally and then pushed again.
Thank you.

Regards,
aronne

Thank you for your contribution @AstonVictor
See you in the next issue xD

Regards,
aronne

aronne → made their first commit to this issue’s fork.

Thanks for your contribution.
MR approved.

Regards,
aronne.

aronne → made their first commit to this issue’s fork.

@AstonVictor hi again :D
Thank you for your contribution :)

Regards,
aronne

aronne → made their first commit to this issue’s fork.

@AstonVictor thanks for your contribution.
MR approved.

Regards,
aronne

aronne → made their first commit to this issue’s fork.

@AstonVictor thanks for your contribution.
MR approved.

Regards,
aronne

aronne → made their first commit to this issue’s fork.

@AstonVictor thanks for your contribution.
MR merged.

aronne → made their first commit to this issue’s fork.

Hi @AstonVictor,
I'm ok with adding a new permission to access prev next links but it can't be a default behavior or nobody will get to see them leading people to think the module is not working properly.

I would rather make it configurable so that only if an "admin" chooses to enable that feature then the permission check will be executed.

Regards,
aronne

Thank you for your contribution, it will get released soon.

Hi guys,
I'm gonna upload a new patch that should solve the problem with the accessCheck call.

aronne → made their first commit to this issue’s fork.

Thank you for your contribution and support.
MR has been merged and will be released soon

Hi @lammensj,
thank you for the great job you've done with this implementation.
I'm gonna create a new release soon.

Kind regards,
aronne

Hi @lammensj,
I think you could add it directly in this module.

Hi @lammensj,
great job again, thank you.
Could you please open a MR or upload a patch so that we can go online with your feature?

Regards,
aronne

Hi @scott_euser,
yes what you're saying makes a lot of sense.
I'm uploading a patch that should do the work.

Hope it helps,
aronne.

Hi @lammensj,
I took a look at your work and I really love what you've done.
I would avoid putting this implementation into a separate module, I prefer the 2nd option.
Tho we must be 100% sure this new implementation doesn't break already existing service descriptions so if you could add some tests it would be great!

Ok i removed the service generator from version 9 and I'm gonna add it back into a new specific version for Drupal 10.
You can install version 9.3.9

Hi @Shreya_th
I just noticed it works only with Drush 12 because the classes it uses are taken from chi-teck/drupal-code-generator:^3
Could you try and check if it works for you with Drush 12?

Hi guys and thank you for your contributions.
Patch applied and ready to be released.

Regards,
aronne.

Hi @sidharth_soman and thank you for your contribution.
Path applied and ready to be released.

Regards,
aronne.

Hi guys,
I'm gonna upload a new patch which should solve the whole things.

Let me know if it works for you as well.

Regars,
aronne

Hi @gorkagr and thank you for your contribution.
Patch applied and ready for next release.

Regards,
aronne

Hi @rocketeerbkw and thank you for your contribution.
Project page has been updated.

Regards,
aronne

Thank you @jurgenhaas for your valuable contribution.
Regards,
aronne