Package install failure

Developing with Concrete
1

I’m developing (updating) a package locally. The package loads fine in docker (running concrete 9.1.2)

I just went to deploy the update to my dev site (EC2 instance in AWS) as I have always done:

  • upload the package folder via ssh
  • login to the dashboard and apply the update via the dashboard

This time, however, when I attempt to install the package I get an error:

error source: /opt/bitnami/concrete5/updates/concrete-cms-9.1.3_remote_updater/concrete/src/View/View.php
line 552: include $_file;
Message: "include(/opt/bitnami/concrete5/packages/esperanto_cards/elements/dashboard/install.php): failed to open stream: No such file or directory"

The site uses a bitnami image, and my package name is “esperanto_cards”.

My package has no dashboard components at all. It has no root level /elements folder, and it has no install.php file anywhere in it.

Why the update process is looking for an install.php file within a non-existent folder in my package path is beyond me.

Note: There was one thing that I did differently this time - I allowed my site (a dev site) to update to concrete 9.1.3 before updating my package. I have no idea if this is related to the problem I now see, but I mention it for completeness.

At this point, I can’t risk deploying it to my production site, but I get no errors when deploying to docker. I don’t know what to try.

I really would appreciate some help, I am at my wit’s end with concrete lately. :stuck_out_tongue: To get this far and now not be able to load the update to my site is nearly the last straw.

2

Hi @Davo - does your package install on a fresh 9.1.3 install?

I would try clearing the cache on your development site and then try installing your package again. You might also try running the upgrade process again in case something didn’t quite finish or something there.

It’s hard to know much more without knowing how your package is constructed, and also the bitnami image is another bit of an x factor there.

3

If what @EvanCooper suggests doesn’t work, you could hack your way around it by adding that element file to your package. It’s just a file Concrete will show right before installing your package. It’s used to give users installation options, but it can also be simply a message or even an empty file.

1 Like
4

Yeah, just to add to what mnakalay said, this file is required if you enable full content swap. It gives you the opportunity to explain what the package is going to do to the site. From

Next, you’ll need to create a file at a specific location. Any time a package enables full content swap, it attempts to load a specific file to give the user more information, above the standard full content swap error. If you don’t provide a file – even a blank one – you’ll get an include error. So, create a file at packages/your_package/elements/dashboard/install.php. You can also put important information about this process in this file as well. It will be displayed to users right before they confirm whether to commit to full content swap.

If you don’t want to put anything in it, you don’t have to.

5

Thank Andrew, I’ll try that and see if I can get the installation working! (Though it will likely be several days before I can try).

I don’t understand, however, why it doesn’t cause an issue locally (docker 9.1.2), or why it hasn’t ever caused an issue before. Is this requirement new in 9.1.3? The docs don’t give a good reason for it except that it is “to give the user more information”. It offers no suggestions as to what information that might be and says that it can be blank. If the file can be blank, perhaps its absence isn’t worth an install error.

In any case, It would be helpful for some documentation on this file (for example if it isn’t blank, how is it rendered (in full, in a frame, within some HTML element)? Does it require typical concrete headers? etc?)

Also with regard to the documentation: Is there anyone who has enough knowledge of the content.xml schema to help with that?

From the Enabling Full Content Swap Documentation:

  • Docs asks reader to use sample content generator and provided link
    • I’ve never gotten to work
    • linked page says “This package is very outdated. You should use …”
    • then points to the 2nd link in the docs for 8+ “Migration Tool”
      • this link has not even README
      • this addon has had a breaking open issue since Dec 2022
      • diving through github issues one MAY find a link to a new 3rd repo not mentioned in the Docs
        • The new 3rd repo however also has a breaking MariaDB issue since Dec 2022
  • The Docs then admit that even with this working, the process creates a file full of things you dont need and that the hardest part is gleaning what you want out from it.

The issue with the Docs in this case is not related to outdated links or changing repos.

The documentation should include a full schema for content.xml that we can reference along with attributes etc. Why can’t we can just write it ourselves for Pete’s sake? Bottom line: I shouldn’t have to troubleshoot 3 outdated plugins to figure out how to add a block in content.xml. The documentation for content.xml should exist (even if a working tool exists for some users).

6

Well, @andrew I finally got time to try and get this working, unfortunately, now that I have added the /elements/dashboard/index.php, file the resulting page does not allow for the content swap - disabling the form options.

Any ideas as to why I cannot select yes?

no-content-swap
no-content-swap1167×757 36.8 KB

I can confirm that my package controller has
protected $pkgAllowsFullContentSwap = true;

class Controller extends Package
{
    protected $pkgHandle = 'esperanto_cards';
    protected $appVersionRequired = '9.0.0';
    protected $pkgVersion = '0.8.9';
    protected $pkgAllowsFullContentSwap = true;
...