I have a folder backup of a plone 3 instance and I want to run it in a VirtualBox with Debian 5. I installed a fresh plone 3.3.5 into /usr/local/Plone as root with the unified installer and I can start it with ./bin/plonectl start. So what are the next steps? The folder structure of the backup looks like:
plone
- bin
- devel
- develop-eggs
- downloads
- eggs
- fake-eggs
- parts
- patches
- production
- products
- src
- theme
- var
- versions
- base.cfg
- bootstrap.py
- build.cfg
- devel.cfg
- production.cfg
- windows-devel.cfg
- windows-production.cfg
- windows-settings.cfg
The original of this backup used varnish and a lot of instances but I only want to restore it with a minimal setup without this stuff.
Was your previous Plone 3.x version 3.2 or later? If so, both old and new use buildout for configuration management. If so, the general plan is:
1) Copy the eggs, develop, zcml and versions directives from old to new. Copy the src and products directory from old to new.
2) Run buildout. Resolve problems that occur.
3) Start your new Plone and see if it functions. Resolve problems.
4) Stop you new Plone and restore the Data.fs file from the old system to overwrite the new Data.fs (under var/). Resolve problems.
The "resolve problems" notes may be insignificant or non-existent if old and new versions are the same. If they aren't, you may need to update some add on package version.
If you're updating from < 3.2, see the guide for updating from non-buildout systems.
Related
I want to set pages to unpublish automatically at a set date on silverstripe 3.
I have seen multiple solutions for this online, mostly with the use of certain modules however none of these are compatible with silverstripe 3 and a lot of the modules say they are now abandoned, if not I get the following error on composer
[InvalidArgumentException]
Could not find a matching version of package xxxxxxxx. Check the package spelling, your version constr
aint and that the package is available in a stability which matches your minimum-stability (dev).
Does anyone have a fully working solution for silverstripe 3?
what you are looking for is most likely the embargo module (https://github.com/silverstripe-terraformers/silverstripe-embargo-expiry). In combination with the queuedjobs modules (https://github.com/symbiote/silverstripe-queuedjobs) for scheduled jobs allows to schedule publishing and unpublishing of DataObjects (for example pages).
You can install the modules with:
composer require silverstripe-terraformers/embargo-expiry symbiote/silverstripe-queuedjobs
and add the configuration to the SiteTree:
SiteTree:
extensions:
- SilverStripe\Versioned\Versioned
- Terraformers\EmbargoExpiry\Extension\EmbargoExpiryExtension
Run dev/build afterwards and you should be able to set dates in the CMS.
On your production environment you will need to ensure to configure a cronjob similar to this:
*/1 * * * * php /path/to/silverstripe-project/framework/cli-script.php dev/tasks/ProcessJobQueueTask
For local testing you should be able to run:
php ./framework/cli-script.php dev/tasks/ProcessJobQueueTask
With the steps above you should be able to have expiry of pages set up in SilverStripe 3.x.
Cheers,
Peter
I am configuring semantic versioning with GitLab for my dotnet core apps and netstandard 2.0 packages.
After reading quite a bit of opinions, some of them contradictory, this is what is clear to me.
A semantic version should be something like
M.m.P.B-abc123 where
M is major version
m is minor version
P is patch version
B is build version (optional)
-abc123 is suffix (optional) in case I use pre-releases. It must start with letter
So the following package versions would be valid:
1.0.0
1.0.1.20190301123
1.0.1.20190301123-beta
1.0.1-rc1
I have the following gitlab script for my versioning
#Stages
stages:
- ci
- pack
#Global variables
variables:
GITLAB_RUNNER_DOTNET_CORE: mcr.microsoft.com/dotnet/core/sdk:2.2
NUGET_REPOSITORY: $NEXUS_NUGET_REPOSITORY
NUGET_API_KEY: $NEXUS_API_KEY
NUGET_FOLDER_NAME: nupkgs
#Docker image
image: $GITLAB_RUNNER_DOTNET_CORE
#Jobs
ci:
stage: ci
script:
- dotnet restore --no-cache --force
- dotnet build --configuration Release
- dotnet vstest *Tests/bin/Release/**/*Tests.dll
pack-beta-nuget:
stage: pack
script:
- export VERSION_SUFFIX=beta$CI_PIPELINE_ID
- dotnet pack *.sln --configuration Release --output $NUGET_FOLDER_NAME --version-suffix $VERSION_SUFFIX --include-symbols
- dotnet nuget push **/*.nupkg --api-key $NUGET_API_KEY --source $NUGET_REPOSITORY
except:
- master
pack-nuget:
stage: pack
script:
- dotnet restore
- dotnet pack *.sln --configuration Release --output $NUGET_FOLDER_NAME
- dotnet nuget push **/*.nupkg --api-key $NUGET_API_KEY --source $NUGET_REPOSITORY
only:
- master
This generates packages such as:
1.0.0 for master branch (stable or production ready) and 1.0.0-beta1234567 for any other branch.
The problem with my approach is that I have VS solutions with multiple projects, each project will be a nuget package and each one has its own version. Sometimes I modify one project but not the other, therefore in theory I shouldn't need to produce a new artifact of the project that I didn't touch nor a new version, of course.
Right now my nuget repository prevents overwriting packages, so If there is a XXX.YYY 1.0.0 and I generate another XXX.YYY 1.0.0 and push it to the repository, it will throw an error and the pipeline will fail.
I have thought that maybe it's not such a bad idea to generate a new package each time I run the CI/CD pipeline, so I considered introducing the build number and have something like XXX.YYY 1.0.0.12345 and, even if I don't touch anything there, the next time a new package XXX.YYY 1.0.0.123499 would be produced.
Is this a correct approach in a continuous deployment scenario? or should I look for a way to make my script smarter and not to produce a new artifact if there is already one with the same version in my nuget repository?
Assuming it's ok to use build numbers always, how do I make sure that only the build number is retrieved from the pipeline but the M.m.P version numbers remain in my csproj as per the following?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Description>Whatever</Description>
<VersionPrefix>1.0.1</VersionPrefix>
</PropertyGroup>
</Project>
I would need something like:
dotnet pack *.sln --configuration Release -p:PackageVersion=$FIXED_VERSION.$CI_PIPELINE_ID --output nupkg
but I don't know how to retrieve the <VersionPrefix> content from the csproj through the CLI.
Any advice, good read or solution for my approach assuming it's valid?
Thanks
The problem with my approach is that I have VS solutions with multiple projects, each project will be a nuget package and each one has its own version. Sometimes I modify one project but not the other, therefore in theory I shouldn't need to produce a new artifact of the project that I didn't touch nor a new version, of course.
Since a continuous integration pipeline is unable to determine if your code should be a new minor or major version you will always have to determine which semantic version your package should get. This makes the whole process a lot easier.
The guys from visual studio team services have this to say about it:
Immutability and unique version numbers
In NuGet, a particular package is identified by its name and version number. Once you publish a package at a particular version, you can never change its contents. But when you’re producing a CI package, you can’t know whether it will be version 1.2.3 or just a step along the way towards 1.2.3. You don’t want to burn the 1.2.3 version number on a package that still needs a few bug fixes.
SemVer to the rescue! In addition to Major.Minor.Patch, SemVer provides for a prerelease label. Prerelease labels are a “-” followed by whatever letters and numbers you want. Version 1.0.0-alpha, 1.0.0-beta, and 1.0.0-foo12345 are all prerelease versions of 1.0.0. Even better, SemVer specifies that when you sort by version number, those prerelease versions fit exactly where you’d expect: 0.99.999 < 1.0.0-alpha < 1.0.0 < 1.0.1-beta.
Xavier’s blog post describes “hijacking” the prerelease tag to use for CI. We don’t think it’s hijacking, though. This is exactly what we do on Visual Studio Team Services to create our CI packages. We’ll overcome the paradox by picking a version number, then producing prereleases of that version. Does it matter that we leave a prerelease tag in the version number? For most use cases, not really. If you’re pinning to a specific version number of a dependent package, there will be no impact, and if you use floating version ranges with project.json, it will mean a small change to the version range you specify.
Source: https://devblogs.microsoft.com/devops/versioning-nuget-packages-cd-1/
As stated first you still need to pick a version yourself for you new package. For the process before the actual publishing of the final package (master branch in your case) you can use the pre release tag to include the build number as the pre release tag.
Without doing anything smart this will publish a new package for every pipeline that is run. The people at visual studio team services and I do not think that this is a bad thing but this will be up to everyone's personal taste
I know it's a little bit late, but maybe others in the future also ask this question.
For background: I work in a small company and we started in the NodeJS world with NPM packages. After a while we also started building with .NET Core and we kind of adapted some things from the JavaScript world. A tool we used heavily is Semantic Release. It automates versioning by parsing commit messages. So you (and everyone developing on the project) use a special format for commits with a prefix type like fix, feat, chore and so on, and Semantic Release parses every commit message since the last release and determines the next version number.
Since in JS world you have to only update the package.json file it kinda works out of the box but for .NET there is a little bit more work to do.
We use the Directory.Build.props file to set the version like you would do with package.json (but it would work in a csproj file too).
Now Semantic Release works with plugins and one plugin we wrote can update files with the version number. So we use it to update the verson number in Directory.Build.Props. But instead of the version in the file you could also directly give the version number to the dotnet nuget cli but we found it more convenient to have it in the file.
So here's the flow we use for our (internal) NuGet packages:
configure Semantic Release to update the version number in Directory.Build.props file (before creating the package)
create the nuget package (we have another plugin for that, but you could just use the exec plugin during the prepare stage of SR
publish the nuget package during the publish stage of SR
The CI script would then just a call to npx semantic-release in an environment that has NPM as well as the .NET SDK available (we use container images for that).
Especially for OP's situation it would be a little bit more complicated, since multiple projects exists in one repository and SR is made to work in a single repository since it works with git tags to determine the last version. So I would advise to split it in multiple repositories.
The benefits are:
automation of release whenever there is a new feature/bugfix
automation of version numbers that adhere to Semantic Versioning (and is unopinionated)
automatically generate a Changelog along with every release
depending on the Git Platform you can also create releases (there are plugins for GitHub, GitLab and others)
you can configure SR to create pre-releases in certain branches, for example you can have an alpha or beta or develop branch
you could also add the commit hash to the NuGet package so everyone using it would know exactly what is bundled in it
Semantic Release creates a commit with the updated package.json (you can configure it to also include the updated Directory.Build.props and I would advise to do so)
And all you have to do is to configure it one time and enforce a special Commit Message style (which one is not so important, you can configure SR accordingly).
I'm working with a copy of Symfony (2.8.9) which works perfectly on my development server.
I've cloned the same repository that this server pulls from, down to my local, and updated composer / ran the Symfony installer. I started getting an error:
You have requested a synthetic service ("request").
I did a little research, and found that this is a bug in the next version of Symfony, 2.8.10, as reported here:
https://github.com/symfony/symfony/issues/19840
I will await the bug being fixed in 2.8.10, but in the meantime, I'd love to be able to downgrade from 2.8.10 to 2.8.9, so my local copy runs and matches the copy on my development server.
I've seen posts regarding changing the version numbers in composer.json, but all my numbers related to Symfony say "2.8", with the minor version number excluded. Additionally, my composer.json file matches on both my dev server and local.
Should I add the minor version number ".9" to the end of the composer.json dependencies, and install the dependencies with composer? Is it enough to add the minor version number to only Symfony-related dependencies, and have all other dependencies work correctly, or are there other version numbers that should be changed as well? Is my approach correct, or is there another way to do this entirely?
You can edit just one line in your composer.json:
"require": {
...
"symfony/symfony": "2.8.*, !=2.8.10",
...
This way, you tell Composer to avoid that specific version. All other dependencies will be retrieved automatically.
Important: you have to remove your composer.lock file first, as Composer will complain that you're locked to the very same version you're trying to avoid.
Disclaimer: backup and test first. I tested on a base Symfony install, not sure if other package will complain.
I am developing a web application with Symfony 2. The code of my own bundle that forms the heart of my application and some configurations files for application-wide settings are controlled by Git (mostly the directories, src/MyCompany/MyBundle, app/Resources/config, etc.) The rest is under control of Composer (the framework, 3rd party bundles, etc.)
Up to now, I ran a ./composer self-update && ./composer.phar update once in a while, pushed or fetched source code from the origin of my repository and everything has been working well.
Today, I started a new fresh working directory and experienced some odd problems.
I performed
git clone <my git repo url> www
cd www
composer.phar install
The composer.json is part of my repository, hence it normally suffices to excute Composer in order to install the framework and all required bundles to get a fully working copy of my web application.
But today, composer.phar install stopped prematurely complainig about missing files. Luckily, I still had my old working directory, so I could copy over the missing files manually, and restart composer.phar. I had to repeat these steps several times until I ended with a fully working application.
The files that were missing are
app/console
AutoLoader.php
app_dev.php
AppCache.php
I thought that these files are part of the Symfony framework and expected them to be installed by Composer. Fot this reason they are not under control of my revision control system.
I found this related question. The answer is very generic und not particularly helpful. All it says is that for example app/console should be included into revision control, because it is not installed by Composer (any longer) and that there is a change in the directory structure due to the transition from Symfony 2 to 3. But I know for sure that app/console was installed by Composer in the past. Hence, something changed.
This leads me to the following questions
Is there any complete, up-to-date and official documentation
what should be included in the repository
what should be in .gitignore
what is managed by Composer?
Is there any documentation how to do the transistion from the old directory structure to the new one in preperation of Symfony 3?
I thought I read all README.md, all release information and everything in "Living on the Edge" of the Symfony site, but somehow I missed this.
The clean way to install Symfony2 from scratch with composer, is to use the following command:
composer create-project symfony/framework-standard-edition my_project_name
This will ensure that all basic structures are created. After that, you can still insert your customisations from the previous project.
Then you can add everything – except app/config/parameters.yml as well as the contents of vendor/, app/cache and app/logs – to your repository.
About transitioning to SF3, I guess there’ll be an upgrade path as soon as SF3 is stable enough to create such a document.
1.1. that depends how you want people to be able to fetch your bundle
1.2. I share with you my own .gitignore: beware I use git for my own use to have a security for my files, not to allow people to get my bundle:
# Cache and logs (Symfony2)
/app/cache/*
/app/logs/*
!app/cache/.gitkeep
!app/logs/.gitkeep
# Cache and logs (Symfony3)
/var/cache/*
/var/logs/*
!var/cache/.gitkeep
!var/logs/.gitkeep
# Parameters
/app/config/parameters.yml
/app/config/parameters.ini
# Managed by Composer
/app/bootstrap.php.cache
/var/bootstrap.php.cache
/bin/*
!bin/console
!bin/symfony_requirements
/vendor/
# Assets and user uploads
/web/bundles/
/web/uploads/
# PHPUnit
/app/phpunit.xml
/phpunit.xml
# Build data
/build/
# Composer PHAR
1.3. everything that is in composer.json
I've just installed MariaDB 5.5 on Windows2k8 64bit, straight forward default install using the windows MSI installer.
If I do a SHOW ENGINES the ARCHIVE engine is missing. How can I include the ARCHIVE storage engine during or post install?
MikeW
We recently had the same problem and could solve it with the following procedure. First check the lib/plugin/ folder for ha_archive.dll. This is the engine driver.
Now you can activate the plugin by adding the following line to your my.ini:
plugin-load=ha_archive
(If you don't have a my.ini, create it according to the example *.ini files in the root folder)
Don't forget to restart your mariadb instance.