Jump to content
tibs

git submodule for wire

Recommended Posts

I'm in no way a github guru, and I may be missing a lot about the implications of what I'm about to suggest, so please bear with me even if it's completely moronic. It's Christmas, after all :)

When a PW site is installed, the original structure is destroyed. In other words, that neat looking .git directory becomes completely meaningless. On the other hand, the wire directory isn't ever touched and, as I see, upgrading PW is done exactly by replacing that directory (and the index.php file, though I believe that one hardly ever changes).

So, the suggestion: Why not make the wire directory a separate github project, referenced from within ProcessWire as a submodule? Downloading PW would now take a git clone --recursive ... (I know, it's overbearingly complex) but upgrading would be super easy, just a single git command. For additional magic and peace of mind, index.php could be moved inside wire, and the original could be just one line to require it from there.

  • Like 1

Share this post


Link to post
Share on other sites

The processwire repository is a place to keep "processwire development". So it's git repository is not meant to comply with anything other than that usecase (the site directory is even excluded). For your own projects you can create a own repository how ever you want. While submodules sound like a great idea it's not used by many, because it's workflow is far from optimal.

Also, why technically moving the index.php's logic would be possible, that strategy does not work for the .htaccess file, which is also changed every now and then dependent on the processwire version. That file does need to be in the root directory to work correctly.

  • Like 3

Share this post


Link to post
Share on other sites
  1. adding a useful use case at practically zero cost (as i understand it would be) is not a bad deal

a component that is developed and used in a mostly independent fashion to get its own repository sounds like an improvement to the workflow

index.php would still be there (as a stub like "<?php require 'wire/index.php';") so .htaccess would need not be changed (as for where it is stored, it isn't part of the installation, it's generated (well, copied) at installation; its template could be anywhere (i.e. within wire))

upgrades from a php viewpoint remain the same: having the code hosted in a submodule changes nothing to whether that code can alter stuff (e.g. the .htaccess file) from outside its tree (e.g. after a pull when PW decides there are upgrades to do: for php, it's the same as if the new version was manually copied, like we do it now)

Share this post


Link to post
Share on other sites

Why not using existing methods? As @LostKobrakai said, git submodules are not used by many because of the peculiar workflow.

There is a module to handle core upgrades: Core Upgrade. Or - if you're familiar with using git - you may consider using wireshell, this is a command line interface like drush for drupal. Instead of  `git submodule update` just execute `wireshell upgrade`. If there are no changes the `index.php` and `.htaccess` files are updated as well.

  • Like 3

Share this post


Link to post
Share on other sites

As far as I understand tibs (just correct me if I'm wrong), his issue is not about how to update PW with one line of cli command or how to update with a few clicks, but it is about how to utilize the official git repo, since this method would fit his workflow, and he thinks that it might be possible to support both the "ProcessWire development" and personal projects based on a workflow he describes.

  • Like 2

Share this post


Link to post
Share on other sites

I also think it could be cool to manage PW versions with composer update command. But I think I saw Ryan write somewhere in the forums he will not split the codebase into separate repos. So I do not think we will be as easy to go as just updating composer.json.

Share this post


Link to post
Share on other sites

Currently just a wet dream. Actually the simpliest way is to rsync/rm/mv the core related files... I hope on a mind change by ryan :)

Share this post


Link to post
Share on other sites
  1. adding a useful use case at practically zero cost (as i understand it would be) is not a bad deal
  2. a component that is developed and used in a mostly independent fashion to get its own repository sounds like an improvement to the workflow
  3. index.php would still be there (as a stub like "<?php require 'wire/index.php';") so .htaccess would need not be changed (as for where it is stored, it isn't part of the installation, it's generated (well, copied) at installation; its template could be anywhere (i.e. within wire))
  4. upgrades from a php viewpoint remain the same: having the code hosted in a submodule changes nothing to whether that code can alter stuff (e.g. the .htaccess file) from outside its tree (e.g. after a pull when PW decides there are upgrades to do: for php, it's the same as if the new version was manually copied, like we do it now)

You're making good points there, but to be completely fair that's your point of view. I'm not so sure that Ryan feels that way, and I certainly wouldn't. Even if it's just a question of committing some changes to separate repository and keeping track of two repositories for issues etc. in my opinion it seems like added workload and complexity compared to current situation.

The point with .htaccess is that while you've suggested this as something that would make upgrading as simple as one git command, the .htaccess file is exactly why this isn't true: it may require manual changes, and thus that single git command is only a partial solution. Note that I'm not saying that making the index.php file a placeholder would be a bad idea in itself; I'm referring to the bigger context here.

Finally, I believe that you can already upgrade your site with a "git pull". The only downsides I can see are that a) it won't upgrade index.php or .htaccess, b) you'll probably have a bunch of unnecessary site-* directories, and c) it will also pull in some other unnecessary files, like a htaccess.txt (.htaccess should prevent direct access to these).

Please correct me if I'm getting something wrong here, writing this in a bit of hurry and probably not thinking everything through :)

Share this post


Link to post
Share on other sites

Thanks for the responses! To be honest, it's not like I'm on a crusade to make this happen, it's just an idea that I kept reminded of so I thought why not throw it out there. (Reading back on my posts I may say sorry if my tone implied otherwise; I was just focusing on the arguments too much  :lol:)

@teppo I think whatever I meant by the .htaccess thing ignored the case of having to make manual changes; I had the impression the upgrade process takes care of that.

@szabesz yes I think you're partially right: it would just look "cleaner" haha. I'm not that concerned about my workflow; strict convictions about small things bring about much overhead  :P

@justb3a thanks for wireshell! I haven't seen it before, I just checked it out, it looks awesome! (omg drush reminds me of much struggling with drupal)

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By thmsnhl
      Hi everybody,
      we started our first Processwire driven project in my new company and for the first time, I was working on one site with more than 2 colleagues on the same site.
      It didn't take long for us to stumble across some problems when multiple developers work at the same time, conflicts with updating the database on vagrant machines, like duplicate entries for page IDs, errors when setting up fields and stuff like this. We ended up working on a dedicated database server, that we linked to our vagrant machines and most of the problems were gone, but the performance of this constellation is really bad compared to our first approach with database running on vagrant machines.
      I already tried to find a solution in the forums but I couldn't find anyone with problems like this.
      So I was wondering: how do you manage projects with multiple developers on vagrant machines in a git-based workflow?
    • By dst81
      Hi,
      I'm a System Administrator responsible for DevOps in our Company. We're trying PW in a single client project atm and experience some glitches with DevOps-/Workflow.
      We have a small team of developers that need to work with the same code base. They all need to be able to develop locally and deploy to a preview/staging environment.
      Our Toolstack contains git for versioning, chef/vagrant or docker for local development/testing and Jenkins for building assets and automatic deployment to the staging-site.
      There's several challenges / glitches in this process that makes me think that ProcessWire hadn't been developed for a use case like ours and is much more intended to be used by single developers that work right on the production system.
      Can you advise me on a suitable workflow?

      There's problems with the assets/files dir that must be shared between the staging website and local environments of our developers.
      We're right now working with symlinks on the staging system that helps to preserve the direcory when deploying from the master branch. but now we tend to use nfs-shares so devs can collaborate with a shared directory.

      The local docker containers can use the same target (the nfs) from inside the containers. But is that the way it needs to be done? Really?
      There's so much work that needs to be done to fit ProcessWire in a DevOps Workflow that we tend to decide to switch to another CMS.
       
      Any suggestions or hints that i might have missed. Am I wrong or is PW really not meant to be used this way. I
    • By louisstephens
      I was going to start working on a new site for myself and wife (a new hobby we have taken up), and had decided to try out Runcloud and Digital Ocean. I got my drop set up on digital ocean, as well as setting up various hooks/databases etc between github and run cloud. However, now I have hit a wall. 
      I cloned my "blank" repository into my local host (managed through MAMP) and dropped in a fresh install of PW, but now I have no idea of how to move forward. Is it best to just work locally, and then push this into a branch, and when ready, change branches and commit all to run cloud? Run cloud gives me an IP address to use for the database, but I can't get my localhost setup to recognize (I just get "Connection refused"). I am also unsure how to actually get my commits to push to run cloud, and handling the new set up.
      I am probably in over my head, but I thought I would try something new as a good learning experience. However, now I am just drowning  . Hopefully someone has some ideas on how to approach this, as I am very eager to get under way.
    • By Barry
      I'm attempting to deploy my site via GIT from bitbucket through Runcloud. I've managed to connect the repo via a webhook and I'm able to pull whenever I commit from local, but I keep getting a "Targetted directory /home/runcloud/webapps/domainname is not a GIT directory inside Web Application thedjcompany"
      I've always deployed via a GUI but we've moved servers and I'm very experienced with GIT, nor do I have any experience with Runcloud, so I'm hoping someone here has some info and can point me in the right direction?
      I'm guessing that I have to initiate the GIT folder within the webapp folder itself but I wouldn't know the command line to get that started.
      Any info/advise would be very appreciated
    • By benbyf
      Hey,
      Been using this starter theme for a little while now and thought I'd open it up on github - https://github.com/benbyford/bb-starter
      It has all my favourite modules installed, .less, some hany .js libraries and a set of blog templates for a simple news / blog setup. The theme is built on the simple theme from PW with additional setup. For more info see the Readme.md file on github.
      See it here - http://bbstarter.nicegrp.com/
      Thanks everyone for your continued work and fun using PW.
×
×
  • Create New...