• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.
  • Chevereto Support CLST

    Support response

    Support checklist

    • ⚠️ Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • ✅ Confirm that the server meets the System Requirements
    • 🔥 Check for any available Hotfix - your issue could be already reported/fixed
    • 📚 Read documentation - It will be required to Debug and understand Errors for a faster support response

Use of undefined constant G_APP_VERSION

Status
Not open for further replies.

snapetom

Chevereto Member
In trying to upgrade to 3.20 from 3.18.3. After replacing the contents of my root server, I'm getting this error:

Code:
** errorId #6baac79a1db7b9e1 **
>> ErrorException [0]: Use of undefined constant G_APP_VERSION - assumed 'G_APP_VERSION' (this will throw an Error in a future version of PHP)
At /app/lib/functions.php:246

The server return actually no content except for a 500 error. Where, what, and how is the best place to set G_APP_VERSION?
 
Oh yes, there where other things missing, too. Like upload.php and the license folder etc.
After I noticed that, I postponed the update.

Now I downloaded the new zip and everything run's smooth after building a new container image.

Btw: I'm a software professional running a licensed chevereo in a cloud native environment (docker container in cluster behind a load balancer with google cloud sql and google storage as backend).
I have the following hints:
  • Bugs should be tracked in Github or any other professional system. Not in a forum (this forum prevents me to report bug. I'd report bugs, if I could do it in Github. I'd even write patches if I find bug, but not in this way)
  • Files should never be written to the filesystem, especially if running in a container. E.g. my User-Avatars get deleted after container recreation (for example due to this upgrade to 3.20). They should be written to the configured storage system (cloud storage in my case), not to the FS.
  • There should be a container image for the professional version which get's the license key for the environment, not from a file. I don't want to build a container for myself, just to add this file.

Just my 2 cents....

Volker

P.S.: here's how to build cloud native software: https://12factor.net/
 
Bugs should be tracked in Github or any other professional system. Not in a forum (this forum prevents me to report bug. I'd report bugs, if I could do it in Github. I'd even write patches if I find bug, but not in this way)
I use this forum, which is connected with licensing so only those with access get my attention. At github I can't focus in those who are actually paying for my work as I can do here. I don't mind using another system, but I need to limit who gets my attention and this is the less hassle free for the user as it works with their Chevereto account.

Files should never be written to the filesystem, especially if running in a container. E.g. my User-Avatars get deleted after container recreation (for example due to this upgrade to 3.20). They should be written to the configured storage system (cloud storage in my case), not to the FS.
Chevereto containers under chevereto/chevereto (dockerhub) are bootstrapped. That's mentioned, is on purpose. Those containers are for those needing to run it like that.

There should be a container image for the professional version which get's the license key for the environment, not from a file. I don't want to build a container for myself, just to add this file.
The distribution you mention is on my plans, for that thing I need some artifacts (like a template repo/action and some scripting) to easily allow customers to build their own image from the license key. My plan is to use github + docker to setup a github secret's based deploy system, feel free to join development when you see the repo spawning.

For now, you could simply use the asset storage env variables to externally store those assets that are troubling you.
 
Status
Not open for further replies.
Back
Top