Installing extensions: 1-2-3...

csf

Davis, thanks. Just did it (five files in total with .css and .js extensions), but the homepage is still a blank screen.

But I just realized I can see the /admin#/ page. From that I can see that the three extensions I had installed (sijad's Links and Pages extensions and s9e's media-embed) are activated but not actually working.

For example, when sijad's extensions are activated they're supposed to show two additional link items in the Admin menu at left, but in this case they are not showing up there. I can deactivate them and reactivate again without errors, but it still doesn't make the menu items for them show up.

Update: ...

I tried to reinstall them using the regular install commands (e.g., $ composer require ...), which appears to work without problem through the re-install process, but then when deactivating/activating again, the extensions threw "500 Internal Server Error". It's Klingon to me, but it seems to be saying there are some database conflicts. Here's extract from the top of the long error:

 POST http://domain.tld/api/extensions/sijad-pages

{
  "errors": [
    {
      "code": 500,
      "title": "Internal server error",
      "detail": "exception 'PDOException' with message 'SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'pages' already exists' in /Users/me/Sites/discuss/vendor/illuminate/database/Connection.php:390\nStack trace:\n#0

It goes on with a bunch more /Users/me... errors with trace numbers.

I'm guessing the plugins might be part of the problem. How would I get them working again?

luceos

csf the pages extension by @sijad is playing up. I'm not sure but it seems your database table (migration) was already created and the extension tries to re-create it. Can you drop the pages table from your database and try enabling the pages extension again?

csf

luceos Yay! That worked. I had to do the same thing with the links table too (his other extension I installed).

I don't see a table for s9e's media-embed extension, so I guess that one's okay? (I'll do a test.)

Okay, so now the big question so I don't screw this up again. Understanding that the production database will always have the latest member discussions and accounts, but local dev will always get the extensions installed first, what should be the workflow to update production with local dev extension development?

@Davis had mentioned something about composer.lock files but I didn't quite understand that.

luceos

csf I don't see a table for s9e's media-embed extension, so I guess that one's okay? (I'll do a test.)

Not all extensions have database tables they need.

csf had mentioned something about composer.lock files but I didn't quite understand that.

It is best practice to copy the lock file of your project to the production server (and not the vendor folder). Once copied you can run composer install (instead of update) to install the dependencies from the lock file. Composer install in comparison to update will always try to install the dependencies from the lock file - you have tested and previously updated to these versions of the dependencies, hence "lock" file.

Please note you should not copy the vendor folder to production.

csf

luceos Good info, thanks!

Can you show me an example "composer install" command? Let's say I copied the .lock file over to production, what's the command to run at that point and where do I do it... In the install directory?

csf

luceos Please note you should not copy the vendor folder to production.

Are you sure about that? I removed it and now I'm getting all kinds of errors on production.

I'm going to copy it back and hope to Hades it works. ?

luceos

csf that would be:

Move into the Flarum installation directory.

composer install --no-dev --prefer-dist

Split up:

install prefers the composer.lock above the composer.json for installing dependencies.
--no-dev will not install dependencies defined under require-dev in each package composer.json file (keeping disk space limited)
--prefer-dist will try to load a tarball from the version control server, keeping bandwidth and temporary diskspace limited.

csf

Thank you. Nice and clear.

Bleed0xx

csf I think he meant that when you want to sync your dev environment to your production environment, you shouldn't copy over the vendor folder. Instead, copy over composer.lock & composer.json to your production server, run the composer commands he detailed and composer will update the vendor folder accordingly as instructed within the composer.lock file.

csf

Bleed0xx Thank you. Critical detail. I thought he meant it was less footprint to carry over to production. I was all excited. An example of communication breakdown in a support situation between a dev and non-dev. No worries.

csf

Haven't done this in a while, but I've copied the composer.lock and composer.jason files to production, got into the flarum install directory and ran:

composer install --no-dev --prefer-dist

But I get...

-bash: composer: command not found

Composer was/is installed.

What might be wrong?

csf

Figured it out after stewing over this series of commands a few minutes and experimenting...

I had installed Composer as a “global” install on WebFaction so I could use it, if necessary, on any webapp I might install in the future, as opposed to just Flarum now. This means the composer.phar file is located in $HOME. So, turned out I needed to create an alias to that file in order for it to work from the Flarum install directory, which the WebFaction guys didn't tell me originally.

These two commands were all I needed to run after tunneling in:

echo -e "\n# Composer\nalias composer=\"php70 \$HOME/composer.phar\"" >> $HOME/.bash_profile
source $HOME/.bash_profile

On WebFaction, you have to make sure the right version of php is indicated, equal to your domain's webapp type set for it in the WF dashboard.

« Previous Page