Mixpost

[privsec]

Can anyone with mixpost pro installed, what are you able to do with the social media apps? Is it simple posts only? Or can you post videos, highlights, reels, etcetra?

[plusone-nick]

@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.

[humptydumpty]

@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.

[humptydumpty]

@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

[girish]

@humptydumpty maybe you can use @service ? See https://docs.cloudron.io/apps/#cron . Those cron tasks run alongside the app.

[humptydumpty]

@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)?

[humptydumpty]

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 to www-data

Using phpmyadmin navigate to:
migrations table

Now, 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.

[humptydumpty]

Full Upgrade Guide:

I followed this doc page:
https://docs.inovector.com/books/mixpost-pro-team/page/upgrading-to-v1

In 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 from root to www-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!

[humptydumpty]

@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

[privsec]

If you install a fresh instance, do you need to worry about the upgrade? Or does this upgrade process have to be followed for each subsequent update?

[humptydumpty]

@privsec a fresh install will get you to v1 but you might still encounter an error when running php artisan migrate. In that case, follow my post above the upgrade guide to get that sorted out. I think we’ll encounter the same issues when upgrading in the future because the file ownership defaults to root and not www-data for newly added files, so the upgrade guide should apply to future updates.

[plusone-nick]

@humptydumpty Ayeee! GG +1
Well done. I have not messed with my instance recently - my Horizon would eventually kill or become inactive somehow and I would have to manually restart.

I was planning on a rebuild and more TS so i will test your steps and report back

[humptydumpty]

@plusone-nick I just checked Horizon and it's still running on my instance. I linked Twitter yesterday and made two posts which worked as intended. I think we got a working and stable guide going for Mixpost! The only issue left is figuring out the Horizon magic. How is it alive?! It feels like we created Frankenstein and now trying to see what makes him tick

[humptydumpty]

@girish We sorted out all Mixpost installation errors but the Horizon mystery remains. Dima has no clue how Horizon is staying alive without Supervisor. Any thoughts?

[privsec]

@humptydumpty and @plusone-nick
Do we need to have Horizon stay alive? Is there a way we can confirm it is up, and if it is not working, what do you do?

[humptydumpty]

@privsec Horizon has to stay alive. It's a must.

Go to your domain.com/mixpost/admin/system/status page and it should all be green like this.

Also, when you ran the command: php artisan horizon

If you wait a few seconds, you should see it report back something similar to a ping test:

bla bla bla.... 15ms
bla bla bla... 8ms

Otherwise, it will say KILLED instead.

If its not working, then you need to redo the installation and apply the "fix" that I posted in comment #83

[privsec]

Ol, so do the steps listed in comment #49 and then comment #83

Would one need to do these same steps every time an upgrade is needed?

How do you retain customers account logins when doing an upgrade?

[humptydumpty]

@privsec Please keep in mind, I just installed it too and I haven't used the app before, so I'm in the same boat as you. However, since we worked out all the errors, the upgrade path should keep all existing posts/users/media/etc. intact.

Start with Nick's installation guide (#49) (skip step 10; somehow the app works without supervisor) and apply the fixes in #83 to get rid of the errors during the outlined steps. Yes, I believe we will have to do the fixes for each upgrade since any new files that get added by the upgrade will default to root ownership which need to be changed to www-data.

My suggestion is to try to install it the first time while keeping in mind that it's a test run just to familiarize yourself with the process. Then, you'll know when to apply the fixes during the intial installation. A cool thing you can do here is to create a backup of the fresh LAMP that you can restore to. If you delete the app and reinstall it, then all the credentials (mysql, phpmyadmin, etc.) will change.

One thing that wasn't mentioned yet, during the installation, you'll be asked "do you want to save these credentials". Say Yes!

I feel comfortable enough to start using the app for my own use. I wouldn't dare give it out to paid clients since it's not a packaged app and Horizon is working automagically but no one knows how because it shouldn't be able to stay alive! With that said, Cloudron backups work and the app itself is stable enough for production use.

[humptydumpty]

@privsec I just realized my mistake. For the initial installation follow #49 (skip step 10; somehow the app works without supervisor) and apply the fixes in #83 to get rid of the errors during the outlined steps.

In the future when you need to upgrade from v1.0 to v1.X, follow the upgrade guide in comment #84 and apply the fixes in comment #83. If you do #49 again, user data won't transfer over.

[privsec]

Ahh, awesome, ok. Thank you