🇺🇸United States @earlyburg

For Drupal site builders you are correct.

Drupal is still the most extensible and secure CMS existant, provided one knows how to leverage it's programming API's
For many sites, Drupals diverse out of the box solutions are good enough.
For larger sites with specific application needs Drupal and Symfony Framework provide more security.
I do not know of any contributed modules that provide proper form field sanitization for instance, although Symfony Framework and Drupals Javascript API provides ample functionality to use, a lot of contrib devs don't use them.

That is and has always been Drupals strongest feature - extensability and cross platform / cross system compatability.
imho. Thank you

Application security is the new Drupal paradigm in .gov space. It's critical for Drupal developers to adopt and learn Symfony framework and learn how to properly harden Drupal.
Drupal's original extensibility was both an advantage and a detriment, because it let inexperienced devs build out quickly with no regard to application performance or security. These applications stand for years, and then when they get hacked or ddosed to death, the clients point to Drupal and say; "Drupal is non performant."
The numbers do not lie.
You can build the best car ever invented, but if no one can drive it or fix it, what is it's percieved value?

@jgoodwill01
Hello. Thank you for your interest in Communico Plus.
I have decided not to renew my license for Communico, as this project did not really get off the ground.
The cost of a license for testing this code is over 7K USD, and I'm not going to renew.

Without an account - development is at a standstill as testing can not be accomplished and new code can't be written.

Apologies. I would consider investing the money if people were using the module. Usage statistics for this code show very little to no use.

Have a nice day and thank you for all the requests for updates on this codebase.
I appreciate it.

@jgoodwill01
Hello. Thank you for your interest in Communico Plus.
I have decided not to renew my license for Communico, as this project did not really get off the ground.
The cost of a license for testing this code is over 7K USD, and I'm not going to renew.

Without an account - development is at a standstill as testing can not be accomplished and new code can't be written.

Apologies. I would consider investing the money if people were using the module. Usage statistics for this code show very little to no use.

Have a nice day and thank you for all the requests for updates on this codebase.
I appreciate it.

I have used this on secure projects:
https://www.zend.com/products/zend-guard

'm having trouble implementing these updates.

"This release adds Twig templating to the Event and Reservation pages. In addition the entire data available from calls to the Communico API are now available at the theme layer."

Any suggestions on working this theme layer into views and fields for use in display manager? Sorry for my novice but using one of the templates in my theme and applying it to the output for "node--event-page.html.twig" I'm not getting any data but am getting the output fields.

All our other content we run through "Layout Builder" to customize field display is that configurable?

Thanks for all your help. Looking forward to getting something functioning and in production one day.

Greetings,
This feature request was to provide complete data for the event pages viewable at '/event/{eventId}'

https://github.com/earlyburg/communico_plus/blob/1.0.x/templates/communi...

* Available variables:
* - event_data (An array containing all event data.)
* - expire_date
* - branch_link
* - calendar_image_path
* - map_pin_image_path
* - reg_url
* - expired_text
* - description
* - one_image

The functionality that you are requesting is for nodes.
I have created a feature request to upgrade node content fields here:

https://www.drupal.org/project/communico_plus/issues/3432825 ✨ Create a way to import images into event pages from API Active

Moving your comments and request for assistance to the feature request to upgrade the event content type.
Thank you

Closed after 30 days of non-activity.

Closed after 30 days of non activity.

Hello,
This feature request has been worked on and is available in the latest release:

https://www.drupal.org/project/communico_plus/releases/1.0.0-beta13 →

Thank you for using Communico Plus.

Hello,
This issue will be closed and marked as resolved after 30 days of non-activity.
Thank you.

Hello,
This issue will be closed and marked as resolved after 30 days of non-activity.
Thank you.

These requests are seperate issues and as such should go into their own request for issue tracking.
I have created two issues for the two requests.

https://www.drupal.org/project/communico_plus/issues/3432825 ✨ Create a way to import images into event pages from API Active

https://www.drupal.org/project/communico_plus/issues/3432824 ✨ Add helpful fields to import data parameters Active

Thank you for the feedback, I appreciate it.
Marking this feature request as complete.

earlyburg → created an issue.

earlyburg → created an issue.

This was fixed by the latest release here:
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta12 →

Hello,
This bug has been worked on and the fix is available in the latest release.
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta11 →

I strongly urge you to read the release notes and the upgrade recomendations.

Thank you for your patience I appreciate it.

Hello,
This bug has been worked on and the fix is available in the latest release.
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta11 →

I strongly urge you to read the release notes and the upgrade recomendations.

Thank you for your patience I appreciate it.

Hello,
This feature has been developed and is available in the latest release.
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta11 →

I strongly urge you to read the release notes and the upgrade recomendations.

Thank you for your patience I appreciate it.

Hello,
This feature has been developed and is available in the latest release.
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta11 →

I strongly urge you to read the release notes and the upgrade recomendations.

Thank you for your patience I appreciate it.

I think it's feasable, but we have to be careful because it's concevable that on big imports on systems with strict php download limits we could run into timeouts.
This may be a better candidate for a queue.
Good idea though - going try to roll this into the next update.
Thank you.

earlyburg → created an issue.

I'm going to create a bug report to review caching behavior for the Communico Filter Block in D10.
The behavior that you are seeing is not per the design,
Thank you for helping debug this and bringing it to my attention.

It would be good to be able to specify this in the admin UI.
Turning this into a feature request.

Investigating this.

By default this module creates a feed block which will load content when a page load happens.
This could be a caching issue, but I would like to learn more about this.
Is the block placed using the Drupal admin interface or instanciated at the template level?

The block feed is created directly from a request to the Communico API, and there are two ways to view event details -
1. Access /event/{Communico event Id} to view details of the event from a call to Communico API.
2. Import events to Drupal as node content here: /admin/config/communico_plus/import.

Communico Plus defines a node type called "event page", which can store event information in the Drupal database.

To achieve the functionality that you mention, I suggest importing events as nodes and then using Views to create a block to display the imported event_page data.

Does clearing the cache in Drupal resolve the event loading issue that you reported?
Thank you. I appreciate your patience with this issue.

Glad you resolved this, but I am mindful that not every user will use a default image style.
The code should permit the use of custom image styles.
Creating a feature request for the project based on this issue, and closing this bug report as resolved.

https://www.drupal.org/project/communico_plus/issues/3423988 📌 Create a way to chose image styles for feed images Active

Thank you for putting energy into Communico Plus. I appreciate it.

earlyburg → created an issue.

From what I can see from your copy-paste, the string that begins with:

<img src="/sites/default/files/styles/medium/public/event_images/SomeImageName.jpg

Does not exist.
Although there could be many reasons for this, I would like to explore further.
1. Does navigating to the page where the block is displayed produce any errors in /admin/reports/dblog ?
2. When you view the developer console, are there any javascript errors displaying?
3. Have you verified that there is no additional markup being passed from Communico that could be affecting the layout?
(Communico allows a limited amount of markup to be used when creating an Event in the Communico admin interface. If the markup passed to Drupal is not compatable with the Drupal theme layer, then problems may result).

I have also done some preliminary testing on my end to verify that changes in the Communico API could be causing this and it does not seem to be the case.

Thank you for your patience with this issue, I appreciate it.

Looking into this.

Hello Laura,
My bad, please disregard.
What is Drupal GovCon all about?
Is it a Drupal distro designed for deployment in the Federal or State government space?
This is extremely interesting to me and I would like to know more.
Thank you!

earlyburg → created an issue.

Symfony Framework:

public function getFieldCollectionByNid($nid, $bundle_type, $collection_name) {
    $field_collection = FALSE;
    $node = \Drupal::service('entity_type.manager')->getStorage('node')->load($nid);
    if ($node->bundle() == $bundle_type) {
      $field_collection = $node->get($collection_name);
    }
    return $field_collection;
  }

Iterate through the field collection thusly:

    foreach ($field_collection as $field) {
      $item = \Drupal::service('entity_type.manager')->getStorage('field_collection_item')->load($field->target_id);
    }

Let me know if you need assistance upgrading this project for a D10 tagged release.

This was fixed in version 1.0.0-beta10. Closing this issue due to two weeks of non-activity.

Resolved by version 1.0.0-beta9 → .

Closing this issue due to no activity for 2 weeks.
Problem was fully addressed in version1.0.0-beta9.

I'd like to help with this, as it would help me out on a project that I'm working on.
What needs done?
Dealing with a composer error when trying to install on D9.5

Problem 1
- drupal/cacheflush[1.0.0-beta1, ..., 1.0.0-beta4] require drupal/cacheflush_entity * -> found drupal/cacheflush_entity[dev-1.x, 1.0.0-alpha1, ..., 1.x-dev (alias of dev-1.x)] but it does not match your minimum-stability.
- Root composer.json requires drupal/cacheflush ^1.0@beta -> satisfiable by drupal/cacheflush[1.0.0-beta1, 1.0.0-beta2, 1.0.0-beta3, 1.0.0-beta4].

Thank you.

I've updated the code and created a new release to address
https://www.drupal.org/project/communico_plus/issues/3363608#comment-150... 🐛 content type fields too generic and conflict with other configs Fixed

https://www.drupal.org/project/communico_plus/releases/1.0.0-beta9 →

Upgrade instructions:
Export and back-up any block configurations that may be relevant.
Update, then completely uninstall this module.
Navigate to /admin/structure/types and delete the content type "event_page" if one exists.
Re-install this module.
Navigate to /admin/config/communico_plus/api, and save your api info, click save.
Check the box labled "Rebuild the filter block select element values:" and click save.

Navigate to /admin/config/communico_plus/import to import content by library location.

This was addressed in the following release:
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta9 →

Upgrade instructions:
Export and back-up any block configurations that may be relevant.
Update, then completely uninstall this module.
Navigate to /admin/structure/types and delete the content type "event_page" if one exists.
Re-install this module.
Navigate to /admin/config/communico_plus/api, and save your api info, click save.
Check the box labled "Rebuild the filter block select element values:" and click save.

Navigate to /admin/config/communico_plus/import to import content by library location.
Thank you for your patience with this issue I appreciate it.

This is a bug. Fixing it today.
https://www.drupal.org/project/communico_plus/issues/3363608 🐛 content type fields too generic and conflict with other configs Fixed

I usually get to these very quickly - please stand by.
Thank you for your patience.

earlyburg → created an issue.

This request has been addressed in the following release:
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta8 →

Note: For this release it is recommended that you completely un-install and re-install this module after exporting any block configurations that you may have.

The WSOD issue was resolved by the current beta7 release here:
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta7 →
Performed an overall code upgrade for D10 compatability.
Testing with PHP 8.1 successful.
https://www.drupal.org/node/3277777/qa →

I will leave this issue set to "Needs Review" for a few weeks than close if no further issues are reported.

earlyburg → created an issue.

I have created a new release for this module found here:
https://www.drupal.org/project/communico_plus/releases/1.0.0-beta6 →
It contains a bugfix that will assist with the error you experienced.

I'm going to create a feature request for the new functionality.
Please look for further updates coming in the near future.

Initially, when I scoped the project I designed code to turn events into nodes, but the modules sponsor at the time blocked that vector. That feature would allow events to be indexed by search api.
I am inspired to create this functionality but it will take until 06/01/23 to roll it out.

With regards to the error you found, can you please copy paste the error message (whole stack trace if you have it), and also let me know which version of Drupal you are using. I will be starting to test this module for D10 soon.

Thank you for your feedback it's very helpful. Please look for more enhancements to this module soon.

@jgoodwill01

API settings should read like:

Communico API URL = https://api.communico.co
Communico Public URL = https://myAssignedAccountName.libnet.info

Please let me know if you need any further assistance with this.

It is my practice to use a very light hand when dealing with my friends in the open source community. It's easy to assume things about people. I was leaving things as they were to inspire an atmosphere of easy-going cooperation among all of the contributors to the project.

I had no consensus, no feedback or any cohesion the way that pull request was handled, and honestly I did not really feel like going into a long dialog about small details in the code. I reviewed the original pull request but not all of it I agreed with. I took the responsibility of honoring the contributor by incorporating the changes that were requested, but I did not merge the pull request because I did not want to point out that there were some issues with the English grammer in the HOOK_help() additions in the pull request.

A lot of my work professonally is developing solutions to the US standard which is enforced by our laws called WCAG 2.0, which requires websites to be handicapped accessable, and translation is incorporated into that law. When I saw the grammer I immidiately thought of the people who would rely on an accurate translation when using a screen reader and translating at the same time.

Also, because I am an American I felt that I would be judged to be too American-centric if I pointed out the english grammer issue.

You had no idea this was going on when you updated the pull request but I am mindful also that you did not notice that the latest tag had addressed almost all the issues except the cosmetic ones that you are pointing out.

I'm doing my best but unless you are volunteering to become a maintainer your changes will have to wait, and I have no intention of merging the pull request - I don't think it would merge anyway because that request is now behind 3 additional commits I have pushed since the pull request was made.

I'm just trying to be polite and tactfull with a rather awkward situation.
I apologize for any problems or confusion I might have caused.

@apaderno Please create a branch with the requested changes and I will merge it.
I manage this codebase locally.
Thank you.

Dependency Injection example works with D9 | D10
 

  /**
   * The entity type manager.
   *
   * @var EntityTypeManagerInterface $entity_manager
   */
  protected EntityTypeManagerInterface $entityTypeManager;

  /**
   * @param EntityTypeManagerInterface $entity_manager
   *
   */
  public function __construct(EntityTypeManagerInterface $entity_manager) {
    $this->entityTypeManager = $entity_manager;
  }


  public static function create(ContainerInterface $container) {
    return new static(
      $container->get('entity_type.manager'),
    );
  }

  /**
   * @param $array
   * @return true
   * @throws \Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException
   * @throws \Drupal\Component\Plugin\Exception\PluginNotFoundException
   * @throws \Drupal\Core\Entity\EntityStorageException
   *
   */
  public function createArticlePageNode($array) {
    $new_article = $this->entityTypeManager->getStorage('node')->create(['type' => 'article']);
    $new_article->set('title', $array[0]);
    $new_article->set('body', $array[1]);
    $new_article->enforceIsNew();
    $new_article->save();
    return true;
  }

This issue has been addressed by the following release:
https://www.drupal.org/project/random_frontpage/releases/2.0.0-beta9 →

Added a help page.

@clarksquared, shiv_sharma

I have been working on my own implementation already.
I'll have a new release done by the end of the day.

Thank you.

These issues are addressed in the latest release found here:
https://www.drupal.org/project/random_frontpage/releases/2.0.0-beta8 →
Please verify and thank you for your help, I appreciate it.

These issues are addressed in the latest release found here:
https://www.drupal.org/project/random_frontpage/releases/2.0.0-beta8 →
Please verify and thank you for your help, I appreciate it.

@Shiv_Sharma - patch file does not contain updates from the latest release, so I can't use them.
Naming conventions do not affect performance.
I will perform more updates soon.
I appreciate it.

@apaderno
The permissions issue has been resolved with the latest release found here:
https://www.drupal.org/project/random_frontpage/releases/2.0.0-beta7 →

I have added the access checks for node queries and also added module specific admin access permissions in the latest release available here:

https://www.drupal.org/project/random_frontpage/releases/2.0.0-beta7 →

There is a discrepancy on line 24 of the patch were it says -
- _permission: 'administer site configuration'
+ _permission: 'access administration pages'

I'm keeping the access checks as-is to keep it more fine grained in a scenario where there are admins with various permission levels on a system. For instance an admin should have access to all admin pages but not settings that can affect specific settings.

I think it would be easy to just create a custom permission setting for this module like "access random frontpage settings" and this would be the best route.

Also it looks like although in this patch we remove the old controller under the old nomenclature, we don't replace it with a new file. :)

Your patch degrades the function of the module.
If I applied it, users would no longer be able to chose a node type to display and would only be able to display the page node type.

Hi thank you for helping out. Feel free to submit a merge request once you have fixed the issues you feel exist.
Thanks!

I think it is resolved now. Thank you for helping, I appreciate it.

Looks good.
I will merge the branch.
Thank you for your contribution.