I am currently hosting several basic sites that are more or less using the same ImpressCMS setup when it comes to modules. Core versions are not so frequent, but I'm using specific flavors of the content module for example where I do regular changes, and it's a chore to update all the sites, without forgetting one here and there.
so I was thinking why not have one build that is common for all the sites, and just make the configuration different depending on the domain name that is used to reach the server? I could see some clashes with the cache that might need to be resolved, certainly if multiple sites use the same theme, off the top of my head, but I'm fairly confident that could be fixed quickly by adding the reference to the site domain.
I'll experiment and keep this thread updated.
It did take me a few attempts to find the best way to accomplish this realignment in my local and remote repos, so I thought I'd share. And, since I haven't use the git command line much, I was working through Eclipse to figure it out. Following the steps above will also make sure you have the latest from the ImpressCMS repository - less to have to compare and merge into your repository.
Thanks for the clear explanation on what to do!
There have been some changes you'll need to adjust your forks and local repositories to stay in sync with the core repository (https://github.com/ImpressCMS/impresscms). What was the 2.0.x branch is now labeled TNG (as in 'The Next Generation') and what was the 1.5.x branch is now the 2.0.x branch. This is to keep in line with the realization we had about the work done and the original scope we had for 2.0. David laid it all out in this post - Version reshuffle. This renaming of the branches in git make things a little more clear when doing work for the various releases.
If you have forked ImpressCMS to work on it, the easiest thing to do is
Alternatively, for moving the 2nd branch (1.5.x to 2.0.x), you could delete 1.5.x from your remote, rename your local 1.5.x branch to 2.0.x, and then push it to your remote. Your remote branch may still have a different upstream branch in the ImpressCMS repository.
If you have any branches that were created from either of those that you are still working in, you will need to update their upstream branch to point to the newly named branch.
If you don't delete the previous 2.0.x branch and the 1.5.x branch from both your remote and your local repository, you'll run into conflicts and potential duplication of branches.
"In all things - give thanks."
Every day, I get up and give thanks because I've been given another opportunity to share life with the people around me. May all of you be blessed as you go through your days.
Thank you for being a part of our community and for what you've shared with us over the years.
PR waiting approval - Password reset: https://github.com/ImpressCMS/impresscms/pull/1527
Issue - Remove banner components from the db: https://github.com/ImpressCMS/impresscms/issues/1528
Issue - CKeditor customizations: https://github.com/ImpressCMS/impresscms/issues/1529
There are a few other improvements to work on. With these and the new theme from @fiammybe, I think we're ready for a release (RC)
After we switched hosting company a few weeks back, I got notified that the SSL setup wasn't performing correctly. It has been fixed now, and going to impresscms.org shouldn't provide you with a warning (depending on the browser you're using) that the connection isn't secure.
c
works for me. I'll get a first beta version ready for inclusion by the end of the week.
We could bundle it the the release like we do with certain modules. At some point, we can make it the core theme.
If you want to include iTheme2 to this version, that would be great. I have been trying different modules and fixing stuff here and there, but I think we are not too far away from a first release of the theme. Getting feedback from different points of view and use cases would be great.
I think we've cleared all the known issues with this release. We had an open issue for MySQL 8 compatibility and I've done a fresh install and navigated through all the core functions without any errors. Time to bundle everything up and get some more hands on it.
Still more - SymLinks allows you to define 'visible in' pages for any URL. For your situation, though, you'd still need a block for every page. You're going to have to deal with this for almost any option to have different content based on the URL. Once built, it should be fairly easy to maintain. Sign in, go to the page, click on Edit for the block, edit and save.
Just brainstorming other alternatives - use a custom block with type PHP. It might be a bit of a chore to figure out all the parameters for each module, but it could be done. Use icms::$module to determine which module it is, then specific branches to process the individual pages of that module. How you would assign content to the block based on the module + page and easily be able to change it... challenging. Custom tags could be used, too.
All in all, I'd default to SimplyWiki for everything.
What you describe is something SimplyWiki does using 'SideContent'.
The concept is to create content related to the main content and assign it as the SideContent for the main page. Then, enable the SideContent block and place it where you will. Based on the page being viewed, the SideContent block displays the content of the page specified as SideContent for the page.
You can see this in effect at www.design-n-bloom.com - visit most of the pages in the menu bar and the block labeled "More Information" is the side content block. 'Send Fresh Flowers' and 'Plan Your Wedding' are the 2 main examples.
Hi,
I want to add a image block to every page on a new site, along the likes of https://www.oudervereniging.be/. I would need the same layout for content, event and blog pages
My idea would be to re-write the existing billboard plugin and make the block page-aware. Is there a way to retrieve information in a block concerning the module and the page the block is shown?
In that case I would handle the images ona page-by-page basis.
I put this one temporarily on hold, so I can help get 2.0 out the door.
OK, it looked like it as well, but I wanted to be certain.µ
I'll see if I can add that part easily, otherwise I'll remove it from the upcoming release and put the relevant code in a branch for later inclusion.
That part of it was never really finished, I believe.
Hi, i'm trying to integrate imtagging into the events module (https://github.com/IsengardBiz/events) and I seem to miss the function that stores the link between a specific tag and the current object. I'm not a real user of that module, so I'm asking myself if that functionality is working all right within the imtagging module?