Should be 1.3.0: Release Jacobs 1.3.0 · pressbooks/pressbooks-jacobs · GitHub
yes. But it is not listed in the release notes. That is why I did not notice it
OK. Now my installation is broken. Site is not working any more. I changed the composer.json and run composer update -W
Pressbooks dependencies are missing. Please make sure that your project’s Composer autoload file is being required, or use the latest release instead.
We were able to get this working with composer for now. In the future, we’ll make packaged versions of the catalog plugin available for each release.
Hi Steel,
Thanks for your response! We have tried to install it now, and it actually broke our whole Pressbooks for an afternoon!
This is what appeared across our whole site.
I asked for some more information from the sys admin for more details I can share here and they said “standard installation method for this plugin doesn’t seem to work.”
I am not sure if you can do anything with this information, but reporting back on the experience just in case.
Best,
Michelle
Thanks @MichelleB – that’s not a lot to go on, but I can confirm that installing from the WordPress interface does not yet work for this plugin (because we haven’t attached a fully built/packaged .zip file to the release itself in GitHub). We hope to have that fixed for our next release. For now, the ‘standard installation method’ to ensure this plugin works correctly is to install it via composer, as described in the plugin readme and partially described in Thomas & my exchange on this thread.
I just wanted to share that I have switched to composer for my updates for Pressbooks on my network. It was getting to feel like a chore since I have 10 different pressbooks plugins that need to be kept up to date and in sync.
My hosting environment already had composer installed, so I just went into my pressbooks directory and did the command ‘composer require pressbooks/pressbooks’ ‘composer require pressbooks/pressbooks-book’ etc…
This is what my composer.json file look like now:
{
"require": {
"pressbooks/pressbooks-book": "^2.25",
"pressbooks/pressbooks-aldine": "^1.18",
"pressbooks/pressbooks": "^6.6",
"pressbooks/pressbooks-stats": "^1.8",
"pressbooks/pressbooks-jacobs": "^1.3",
"pressbooks/pressbooks-shortcode-handler": "^1.0",
"pressbooks/pressbooks-fitzgerald": "^1.6",
"pressbooks/pressbooks-donham": "^2.1",
"pressbooks/excalibur": "^0.6.2",
"pressbooks/pressbooks-network-catalog": "^1.2"
},
"config": {
"allow-plugins": {
"composer/installers": true
}
}
}
When I first started managing Pressbooks, we did all our upgrades from Pressbooks itself, since Pressbooks had been configured to use the Github updater. This is when my life was easiest, because Pressbooks updated just like every other WordPress plugin on any other server (despite not actually being in the WordPress plugins directory. This was also good for teaching other open source users because Pressbooks felt familiar to keeping WordPress up to date. I had several problems with upgrades that I documented in a github ticket Github Updater for Pressbooks 5.35 Release Fails · Issue #2818 · pressbooks/pressbooks · GitHub
If you read through my ticket there, you can see that although the problem showed up because I was using the github updater, sometimes, even when I went and got the package on github upgrades were broken, because they were missing dependencies required in each packages individual composer file. So even when I downloaded the latest release from github, I would install it through the regular WordPress process, and I would be prepared to FTP into my server to run ‘composer install’ to fix dependency issues.
I’ve made this switch now to fully using composer, so that I can just plan to update from the command line anyway. For the last few major wordpress upgrades, I have started using WordPress CLI instead of upgrading from the web interface.
What I have described though in the last three paragraphs is increased technical competencies and higher barrier of entry to get Pressbooks working properly. As an open advocate, my hope is that these systems can be majority run by librarians and instructional designers, with only occassional assistance from a sysadmins, and I’m seeing increased technical barriers.
I run SUNY’s Domain of One’s Own program which we call SUNY Create, where I teach users how to install and run WordPress, Moodle, Pressbooks, Commons in a Box, and recently a fellow DoOO admin came to me and asked me to start teaching them about Pressbooks. They kind of gave up because they got caught up in too many little things that broke their site. The open-source install instructions said that Pressbooks usually works with the most recent version, but they installed at a time when Pressbooks wouldn’t work with the most recent version.
The dependencies in Pressbooks have always been a little bit of a challenge because its hard to anticipate what everyone’s environment will look like. They eventually got through everything except the MathJax microservice, which documentation still calls for an EOL version of Node.JS. I felt really badly that at the end of the day, this person who I consider an open source advocate kind of looked at Pressbooks and said, “this doesn’t look like the kind of software I can manage day to day.” They transitioned to looking at Manifold because they have a dockerized version and have public docker-compose files that build the entire environment quickly and easily.
I wonder if a dockerized version of Pressbooks would ever be possible, where there is a composer file that spins up Pressbooks and all of its dependencies? I know that for development, the team uses a combination of tools (bedrock, trellis) some that I am familiar with and some that I am not. I wonder if the open-source install instructions should just match the process that the Pressbooks teams process more closely. That’s why I switched to a composer update process, I figured that I was running into problems too often, and if I was upgrading in the same way that the Pressbooks internal team upgraded, then maybe I would run into fewer problems.
At the end of the day, I’d like to see it be easier to host Pressbooks. I have this core value that you need to be able to host your own content and own your own version of OER. It’s part of why I advocate for Pressbooks instead of other libre OER systems that are more centralized.
2 Likes
Hi @beckej – we have a bedrock repo that open source users can start with/fork for their own needs. It’s at GitHub - pressbooks/bedrock: WordPress boilerplate with modern development tools, easier configuration, and an improved folder structure.. @MichelleB and @t.dumm I just released a new version of Pressbooks Network Catalog (1.3.0) that I hope/believe can be installed/updated through the standard WordPress method. See Release Pressbooks Network Catalog 1.3.0 · pressbooks/pressbooks-network-catalog · GitHub. You’ll want to download the build asset with the box in front of it:
I gave the plugin a try on a working current Pressbooks install with php8.1 that never had a version of this plugin installed before by composer. I was able to install and activate the plugin, but the catalog page looks like this:
https://content.akad.ch/katalog/
I checked that the correct template is used for the catalog page. Any idea what to do? I know that with the composer installed plugin in a different Pressbooks install, I had the same problem originally. But I do not remember how I fixed it, thanks to @SteelWagstaff
@t.dumm I think there might be a problem with the page template and the cache? Try switching the page template to ‘Default template’ in ‘Page Attributes’, click ‘Update’, and then change back to catalog and update/save again.
@SteelWagstaff I did that already and did it again and also cleared all cache and offline data. But the catalog page layout is still broken.
What I notice in the browser console is the following CSS error message:
Uncaught SyntaxError: expected expression, got ‘*’ app-4be0f7f0.css:1
If I validate
with Oxygen, I get CSS error messages. I am unable to prettify the CSS to check whether the error messages are related to special CSS or a real issue with the dist CSS.
@SteelWagstaff I cannot update the catalog plugin yet on the network that you refer to, as that network is still on php8.0
@t.dumm we broke the build process for this plugin inadvertently in our 1.2.0 release by bumping Vite to version 4 without updating our build config file correctly: Make compatible with Vite 4 · Issue #181 · pressbooks/pressbooks-network-catalog · GitHub. We should have this fixed in our next release (hopefully later this week).
@t.dumm new release of catalog (1.3.1) now available: Release Pressbooks Network Catalog 1.3.1 · pressbooks/pressbooks-network-catalog · GitHub. Should fix the issue we were having with built JS and CSS assets. If you’re developing locally, you may need to delete the ‘node_modules’ folder in the pressbooks-network-catalog folder with these commands
rm -rf node_modules
npm i
npm run build
The first line will delete the installed node_modules in the repo. The second will install the node modules as specified in the project’s package.lock file and the third will build the required JS and CSS assets needed to properly display the catalog with expected functionality.
@SteelWagstaff I was able to update the plugin and the new version is working correctly. Thank you!
1 Like
@SteelWagstaff I can confirm that this fix has resolved the issue for us as well (replying on behalf of @MichelleB). Thanks so much!
1 Like