Dashboard > Extend concrete5 > Upload Package
Package magic can 'upload' packages from a range of sources, as detailed below.
Validation of zip archive contents
Uplods are checked for a range of issues and rejected if any problems are found. You have checkbox control over which issues are enabled, by ticking to ignore specific checks. Further checks can be added by speifying glob matches.
- Ignore dot files
- Ignore __MACOSX
- Ignore Thumbs.db
- Ignore .sh and other shell scripts and batch files
- Ignore executable file types such as .exe
- Ignore file types containing non alphanumeric characters
- Do not check compilation
- Allow current version to be overwritten
- Skip validation for files matching *glob* patterns
- Additional validation to reject files matching *glob* patterns
If you have a good reson for installing a package containing a file that fails one of these validation checks, you have two choices. You could disable the entire class of checks by deselecting the applicable checkbos. Or you can specify a glob match to exclude just that file from checks using "Skip validation for files matching". For example, if you want to allow .htaccess files, a glob pattern of */.htaccess would allow any subdirectory of the package to contain .htaccess files.
You can similarly specify additional validation through "Detect files matching". Here each line comprises a glob match for the check to apply, then text to use as an error message. For example, entering */Gruntfile.js unwanted Grunt will complain if the package contains a Grunfile.js and provide the error message "Unwanted Grunt".
When a new package is successfully uplaoded, the package is immediately shown in the core Extend concrete5 > Add Functionality > Awaiting Installation section, ready for you to do any of Install, Apply Package Build Tools or even download a rebuilt archive without installing.
When an already installed package is uploaded, the default behaviour is to run the upgrade immediately. If that is not possible, the core Extend concrete5 > Update Add-ons page is loaded to run the upgrade.
Any update to a package source is made atomically. After running a Package Magic Upload, the package source will be either all the new source, or should the upload fail, all the old source.
Upload Package > Direct Upload
Upload a package zip file.
Select a concrete5 package zip archive file to upload to this site from your own computer. Unlike Package Magic Starter, you have full control over how packages are validated. If you want to allow system files, you can. If you want to preclude files matching a specific path, its simply a matter of specifying a glob pattern.
Upload Package > From File Manager
Select a package zip file from the File Manager.
Select a concrete5 package zip archive file that has already been uploaded to the site using the File Manager. Allowed File Types must be configured to include .zip files.
Dashboard > System & Settings > FIles > Allowed FIle Types
Upload Package > From Local Repository
Get archive from a structured repository directory.
Once configured with a local system directory as the root of the repository, package archives will be selectable from the structure beneath that directory. The directory path must be directly accessible to the web server.
You can even configure multiple repositories and select between them. For example, perhaps you like keep a separate directory for each customer project.
You can read more about repository directories in Package Download.
Upload Package > From URL
Get archive from URL or filepath.
Enter the URL or filepath from which a concrete5 package zip archive file can be copied to the server. If a filepath is entered, it must be directly accessible to the web server.
Sourcing packages from GitHub
Archives for packages downloaded form GitHub projects do not usually contain a root directory named after the package handle. To accomodate such packages, on the upload dialog look for the section Advanced Options and check Fix paths in archive from package handle.
This will look inside the archive to get the package handle from the controller and fix the file paths to match the handle. Caution - this bypasses some checks on correctly formed packages. This option may be necessary when downloading from GitHub, where the internal directory may not follow the concrete5 naming requirement. Beware that archives from GitHub may not actually be concrete5 packages! For example, they may need comp[oser or other build dependancies to be resolved before they can be installed.
Coping with execution time limits
Uploading a package can be hindered by systems outside your server. For example, uploading a file from an external URL or by direct upload are dependant on the responsiveness of the external system the file is being uploaded from. If the external system is heavily loaded, it may be a little tardy about serving the file you are uploading, so causing the upload to fail.
Should that happen, often simply trying again will be successful.
Should you continue to have problems with a package or source, Package Magic provides some tricks to spread the load and hence achive a sccessful upload:
- In Advanced Options, check to Do not automatically run package update, so unpacking and update become two seperate actions. You can then run update manually through Extend concrete5 > Update Add-ons
- In Relaxed Validation, check to Do not check compilation. A package that is not already installed will stay "Awaiting Installation" and you can then use Extend concrete5 > Package Tools > Check Compilation to run a compilation check file-by-file.
- Upload the package archive .zip using the concrete5 file manager, then use the Package Magic source Upload Package > From File Manager.
Last updated: 2 months ago