Mixpost
-
@plusone-nick Technically, there should be no error in those functions from Kernel.
I think you had some errors elsewhere and thought this was the solution. If you now have Mixpost functional, try to return ":void" and see if everything is fine.
-
@lao9s Everything is still green @humptydumpty make the change too
Docs update β Removed the stepDima, I have a question β What happens when using the same pro/enterprise license on two instances? Does the local/production env var enable any test/dev feature?
-
Using the same pro license in production on two or more instances is not allowed.
Using the same enterprise license in two or more instances is allowed and nothing happens.
The
local
env is used when you want to modify the code, usually, the work is done locally. For example: if you have envlocal
and want to run a migration, it won't ask you if you are sure to migrate or not, it will simply run the command. -
@plusone-nick I tried upgrading to v1 using these steps (the standalone route, not Docker): https://docs.inovector.com/books/mixpost-pro-team/page/upgrading-to-v1
I ran into an error on this step:Run php artisan migrate
APPLICATION IN PRODUCTION. β Are you sure you want to run this command? βββββββββββββββββββ β Yes β ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ INFO Running migrations. 2023_08_12_121215_create_job_batches_table ............................................................................................. 15ms FAIL In Connection.php line 795: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'job_batches' already exists (Connection: mysql, SQL: create table `job_batches` (`id` varchar (255) not null, `name` varchar(255) not null, `total_jobs` int not null, `pending_jobs` int not null, `failed_jobs` int not null, `failed_job_ids` longtext n ot null, `options` mediumtext null, `cancelled_at` int null, `created_at` int not null, `finished_at` int null) default character set utf8mb4 collate 'utf8mb 4_unicode_ci') In Connection.php line 580: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'job_batches' already exists
I continued with the other steps regardless of the error. The went well. But the app shows a blank white page. Restoring to a working backup for now.
If this doesn't make you appreciate Cloudron even more, then I don't know what will!
-
@plusone-nick Step 10 isn't necessary at all. I messed up the upgrade so I loaded up a fresh LAMP install and re-did the installation steps without installing supervisor (step 10) and it works fine.
I still encounter an error when I get to
php artisan migrate
during step 7. It's similar/same error I get when upgrading from 0.10.X to v1. The app loads a blank white page if you're upgrading but works fine regardless of the error if it's a fresh installation. At one point, I had Horizon get killed after starting it. I tried so many things that I lost track of what I did, but I couldn't get Mixpost to upgrade successfully.Anyway, I don't remember seeing SMTP stuff in 0.10.X. For v1 in the .env file:
#SMTP MAIL_MAILER=smtp MAIL_HOST=smtp.mailgun.org MAIL_PORT=587 MAIL_USERNAME= MAIL_PASSWORD= MAIL_ENCRYPTION=tls MAIL_FROM_ADDRESS="hello@example.com" MAIL_FROM_NAME="${APP_NAME}"
I guess we need to fill that from the info in
credentials.txt
. -
@humptydumpty oh okay, noted. Have you done further testing? The step is not needed, so it must be installed already?
I have not gone through any of the update/upgrade process, so I cannot speak for certain.
Have you tried just installing to the βv1β instead of the upgrade process?Something like:
composer require inovector/mixpost-pro-team "^1.0"
composer create-project inovector/mixpost-pro-team-app "^1.0"
Note: Not positive, have not tested. Could be totally wrong as composer is new to me.Although they are βdifferentβ I have been also referencing the existing app install docs to better understand the overall app install process along with how composer works in both use cases.
Regardless, @lao9s or @girish could better advise on this as it's a bit above my head at the moment to response definitively.
-
@plusone-nick I followed this guide in my attempt to upgrade to v1: https://docs.inovector.com/books/mixpost-pro-team/page/upgrading-to-v1
If I try to actually install supervisor, it says
supervisor is already the newest version (4.2.1-1ubuntu1).
That's why I decided to skip it entirely for the new installation. Re-reading the mixpost docs, it looks like supervisor should be installed on the VPS and not in the LAMP container. Maybe that's why it's failing to install. Unless Contabo has it pre-installed on their ubuntu-server images? IDK.There was no need to specify v1 when reinstalling on a fresh LAMP. Simply going through your steps again will get you the latest upgrade. Unless, you meant when trying to upgrade a 0.10.x app. For that, I followed the guide I posted above which does use the command line you mentioned (with v1 at the end, etc.) and that didn't work. Ended up with a blank white page and with some more tinkering, Horizon would kill itself.
I don't mind upgrading Mixpost manually if there's no package for it. But, the process has to be documented well for Cloudron by @lao9s. During my troubleshooting earlier, I had to use Cloudron's backup restore multiple times, so I know that works. However, I think that's when Horizon decided to start killing itself after I restored a working 0.10.x backup. Currently, I have a persisting backup for a fresh LAMP (no mixpost installed) and another persisting backup with a working v1. I could test a backup restore of the working v1 to see if Horizon will kill itself again but that would have to wait for later. I've been at this all day, I'm exhausted.
-
@girish Mixpost requires a process monitor to be installed. I'm running into issues when trying to install Supervisor in the LAMP terminal (did not do it for the entire VPS). Does Cloudron have that installed or is it using a different process monitor? I ask because it seems to be installed according to the error message I get when trying to install supervisor.
Reading package lists... Done Building dependency tree... Done Reading state information... Done supervisor is already the newest version (4.2.1-1ubuntu1). W: Not using locking for read only lock file /var/lib/dpkg/lock-frontend W: Not using locking for read only lock file /var/lib/dpkg/lock E: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (2: No such file or directory)
https://docs.inovector.com/books/server-configuration-mixpost/page/installing-configuring-supervisor
-
@humptydumpty maybe you can use
@service
? See https://docs.cloudron.io/apps/#cron . Those cron tasks run alongside the app. -
@plusone-nick With Dima's help, I fixed the issues that were blocking the upgrade from 0.10.4 to V1. I'll post the process in a separate post. However, my question about supervisor hasn't been answered by anyone yet, and I'm baffled how the app is working without it.
My question to you is how did you get supervisor to install properly, and where did you install it? On the VPS level (as root alongside Cloudron) or within the app's terminal (containerized)?
-
I reached out to Dima on Mixpost's Discord, and we figured out what is causing the error when running
php artisan migrate
. In short, there were two issues:- Mismatch in the migration file naming of what's in the file manager and what's in the database migration tables.
- Wrong ownership of the migration table file that gets created with root and has to be www-data.
To Fix it:
You need to open both the file manager and access the database at yourdomain.com/phpmyadmin (login credentials are in
/app/data/phpmyadmin_login.txt
).In the file manager navigate to:
/app/data/mixpost-pro-team-app/database/migrations
change the ownership of any files with
root
towww-data
Using phpmyadmin navigate to:
migrations
tableNow, compare the file names of both and rename the files in the file manager to match what is in the database. For me, the date was different.
Note: create_mixpost_v1_tables will not exist for you yet. That gets created during the upgrade steps later on.
-
Full Upgrade Guide:
I followed this doc page:
https://docs.inovector.com/books/mixpost-pro-team/page/upgrading-to-v1In the terminal:
cd to app/data/mixpost-pro-team-app
run command:
composer require inovector/mixpost-pro-team "^1.0"
run command:
php artisan make:migration create_mixpost_v1_tables
Go to the file manager:
/app/data/mixpost-pro-team-app/database/migrations
and change ownership of 2023_08_21_121342_create_mixpost_v1_tables.php file fromroot
towww-data
Note: your file name will differ as it will have a different date at the beginning.Open
2023_08_21_121342_create_mixpost_v1_tables.php
and replace its content with the migration content from the source guide I posted above. For reference, the code is:<?php use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Schema\Blueprint; use Illuminate\Support\Facades\Schema; use Inovector\Mixpost\Models\Account; return new class extends Migration { public function up(): void { Schema::table('mixpost_accounts', function (Blueprint $table) { $table->boolean('authorized')->default(false)->after('data'); }); Account::withoutWorkspace()->update(['authorized' => true]); Schema::table('mixpost_settings', function (Blueprint $table) { $table->unique(['user_id', 'name']); }); Schema::create('mixpost_user_two_factor_auth', function (Blueprint $table) { $table->id(); $table->bigInteger('user_id')->unsigned()->index(); $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade'); $table->text('secret_key'); $table->text('recovery_codes'); $table->timestamp('confirmed_at')->nullable(); $table->timestamps(); }); Schema::create('mixpost_pages', function (Blueprint $table) { $table->id(); $table->uuid('uuid')->unique(); $table->string('name')->nullable(); $table->string('slug')->unique(); $table->string('meta_title')->nullable(); $table->text('meta_description')->nullable(); $table->string('layout'); $table->boolean('status')->default(0); $table->timestamps(); }); Schema::create('mixpost_blocks', function (Blueprint $table) { $table->id(); $table->string('name'); $table->string('module'); $table->json('content')->nullable(); $table->boolean('status')->default(0); $table->timestamps(); }); Schema::create('mixpost_page_block', function (Blueprint $table) { $table->id(); $table->foreignId('page_id')->constrained('mixpost_pages')->onDelete('cascade'); $table->foreignId('block_id')->constrained('mixpost_blocks')->onDelete('cascade'); $table->json('options')->nullable(); $table->integer('sort_order')->nullable(); }); Schema::create('mixpost_configs', function (Blueprint $table) { $table->id(); $table->string('group'); $table->string('name'); $table->json('payload')->nullable(); $table->unique(['group', 'name']); }); } };
Run command:
php artisan migrate
Note: if you get an error at this step, see my post above this one for a fix. Basically, it is a file name mismatch of what's in the /migration folder and the migration table in the database. Rename the file manager files to match the database to fix.run commands (one at a time):
php artisan vendor:publish --tag=mixpost-config --force
php artisan route:cache
php artisan mixpost:clear-settings-cache
php artisan mixpost:clear-services-cache
php artisan horizon:terminate
Restart the app
run commands:
cd /app/data/mixpost-pro-team-app/
php artisan horizon
Make sure Horizon isn't killing itself and that it reports back. If so, you are DONE!
-
@girish something is keeping horizon alive. Dima and I have no clue what or how. This cron job isn't doing that. Any idea what's going on? Is there some function that comes preinstalled with Cloudron that could be replacing/handling the supervisor job?
* * * * * cd /app/data/mixpost-pro-team-app && php artisan schedule:run >> /app/data/null 2>&1