Is it possible to update an existing theme/plugin that does not currently have the URI docblock?

[scofennell]

Hello!

We are continuing to get to know this awesome plugin, but ran into a roadblock today while training other team members on it's use. Here's the deal:

1. We have a theme on the server, live, without the Bitbucket Theme URI docblock item.
2. We make an update to that theme locally, boost it's version number, and add the Bitbucket Theme URI to the docblock.
3. We push this update to bitucket.
4. We try to use GHU to update it on the live server, but we get this error message:

It seems like at this point, we would have to delete the theme from our live server in order to get it started with GHU? That's a little scary and is also extra work. Any advice? I might be missing something really basic -- apologies.

[afragen]

Answer to the issue title is no.

You're trying to overwrite a theme that already exists using the remote install feature. It's a great feature to initially install the theme.

What you need to do after updating the theme upstream is to go to the core update page and click on the 'Check Again' button.

If the update doesn't show after, you might need to click on the 'Updates' link in the sidebar or the updates icon in the admin bar.

If the Bitbucket Theme URI is not present in both the local and remote style.css files then you will have issues.

Is there really something worthy of blocking out in your image?

[scofennell]

Thank you for the reply!

I'm not sure if part of my server path is worth blocking out or not, just being paranoid.

This is unfortunate -- I was hoping that this plugin would eliminate the need for modifying or even accessing files via ftp, but it sounds like I will need to touch them via ftp in order to add the Bitbucket Theme URI. Am I reaching the right conclusion there?

[afragen]

No you shouldn't have to use FTP, except perhaps only once to add the header. As the header will exist in subsequent updates no further use of FTP will be needed.

Let's start over.

1. Make sure you have backups.
2. Make sure the version on Bitbucket has the appropriate Bitbucket Theme URI header
3. Make sure the style.css file for the theme on the site has the Bitbucket Theme URI header
4. If your are using tags the tagged version must have the header too.

That's it. Any updates should be noticed in the update page, though transients are set to 12 hours. Transients can be deleted by clicking the 'Check Again' button.

[scofennell]

Thanks for responding. My question is around precisely this point only:

No you shouldn't have to use FTP, except perhaps only once to add the header.

That, for me, is a bummer, because I have a large number of themes and plugins on the server and it would be phenomenal if I did not have to touch them via FTP, even once, just to add the header.

Is there any way to get around this requirement?

Sorry for all the questions around this point. Your use of the word "perhaps" left a glimmer of hope for me that I wanted to get absolutely clear on before proceeding to train other team members on the process.

[afragen]

Well, once you have the header in the Bitbucket repo's style.css, you could delete the theme from the server and then reinstall using the remote install feature of GitHub Updater.

You should probably switch to a default theme first and test on dev site, but it should work.

[afragen]

Make sure that the correct headers are in the upstream files. Bitbucket Theme URI and Bitbucket Plugin URI, respectively.

[scofennell]

Some of our themes are active on dozens of sites, so the thought of deleting it, even briefly, is probably not something we can build a routine around. As unpalatable as it is, an FTP touch to add the header would be preferable over actually deleting the theme, even briefly.

This is an awesome plugin, and I can't claim to know how it does what it does. If you can conceive of a way to add the header from bitbucket to the server, it would be a huge win for me.

Thanks for your time!

[afragen]

If you're updating plugins you will need to use FTP to delete or add the headers as deleting the plugin form inside WP will also likely delete any plugin associated data.

[afragen]

Some of our themes are active on dozens of sites, so the thought of deleting it, even briefly, is probably not something we can build a routine around. As unpalatable as it is, an FTP touch to add the header would be preferable over actually deleting the theme, even briefly.

This is only necessary once to have the header installed in the file.

[scofennell]

I totally get that, thank you for explaining that. I'm just a little dev-sad because it would have been a huge win to eliminate FTP from our process immediately.

[afragen]

How many sites and how many themes? I assume since you're asking that your current method of updating ALWAYS involves FTP.

[scofennell]

We have about 1,000 sites, maybe 700 themes, 200 plugins.

You're absolutely correct -- right now our work always involves FTP.

[afragen]

You know you don't have to do this all at once. Just add the GitHub Updater plugin to the sites and at your next update make sure the header is in place.

[scofennell]

For sure, I totally get that. This is an awesome solution, that's why I am taking the time to get super clear and build our deployment process around it.

That said -- it would have been great to totally eliminate FTP from that process. It's not uncommon for one of our junior devs to touch a dozen theme/plugin folders in a single day.

[afragen]

For sure, I totally get that. This is an awesome solution, that's why I am taking the time to get super clear and build our deployment process around it.

Please ask whatever questions you need. I think once you have this working you will look back and say, "I can't believe I used to do this via FTP every single time."

That said -- it would have been great to totally eliminate FTP from that process. It's not uncommon for one of our junior devs to touch a dozen theme/plugin folders in a single day.

Sounds like the junior devs can have you all automatically updating in a few months. :+1:

[afragen]

BTW, you can use services like ManageWP or iTheme Sync with GitHub Updater.

[ghost]

InfiniteWP also .. although it is not handling child themes (nothing GitHub Updater can do about it though)

@scofennell thank you for describing your context (it is not so usual)

If you have a moment, you could check out https://github.com/franceimage/wp-alt-repositories It is nothing as mature as Github Updater but it does not impose any change in the style.css to express an update. The plugin just relies on a new commit or new tag.

I'd appreciate your feedback to know if this approach serves a purpose. Thanks

[afragen]

@scofennell I'm curious as to how you have proceeded. Care to share?

[scofennell]

That's a good question. I'm just one team member, but my sense is that we have largely ignored GHU because of the ftp touch required to initially add the header.

Our team has had a lot of process bloat/process change in the last 2 years. I get the sense that changing our processes yet again, as I was attempting to do when I was more active in this repo, is going to be a difficult pill to swallow unless it's super, super simple. The act of having to determine if a theme/plugin has the header yet, and then adding it if needed, or just using GHU from wp-admin if it already has it ... It makes this transition too annoying for us right now. It's easier/lazier to just act on the assumption that you have to touch a project via ftp each time. This is partially because we have hundreds of projects, and might only touch each one every few months.

I realize that sounds pretty weak and undisciplined. I was just thinking recently that I need to talk to the rest of the team about this and get a clear picture of our compliance rate.

[afragen]

@scofennell currently the develop branch (and the next push to master) support both iThemes Sync and InfiniteWP for remote management. There are new settings in the Settings page. FYI, IWP doesn't yet support child theme updating.

If you just added the correct headers to everything currently in the repos then the next time they were FTP'd to the sites the correct headers would be there. Is it really 700 unique themes and 200 unique plugins? It shouldn't take too long to add the headers to the repo files. Then at least they would be there next time someone does something.

I cannot speak to how your team manages itself. But certainly I think you've stumbled upon something, that if implemented, would significantly improve your workflow over time.

Start new sites by installing GitHub Updater then use the Remote Install feature to add plugins/themes. If the repos already have the correct headers then updating will just happen.

Perhaps inviting your team members to follow this issue might help.

[scofennell]

I think what we might do is just make a ticket to batch through all our folders and add the damn headers.

[afragen]

I think what we might do is just make a ticket to batch through all our folders and add the damn headers.

This will be the simplest/quickest way to get started.

Just wait until the first time you can use a service like iThemes Sync or InfiniteWP to update those custom plugins and themes from a single place. Let me know what everyone thinks about not having to do the FTP dance then.

[afragen]

Hey @scofennell it's been over 6 months. Have you and the team been making any progress?

[scofennell]

Hey Andy!

Ultimately, our adoption of your plugin was extremely lackluster, due to three factors.

1) The header thing. 2) We're not really the type of team that enforces things, per se. 3) I'm not positive, but we did seem to be getting some very slow page loads when your plugin was active.

I've spent the last month or so building our own version that does exactly what we want, no more, no less. It only works with Bitbucket, it updates, it installs, all it needs is the version number header (which we like since it forces us to actually increment the version number in our work), no extra headers or such, no performance concerns.

Some key points:

• Ours calls Bitbucket upon activation and on a cron job and gathers a list of all 800 of our repos. It then sorts them by date updated and drills into the recent 30 to build details like "is_installed" or "needs_update".
• There's also a UI to do that stuff on demand and for specific repos. It's powered by an autocomplete, so it's easy to find the correct repo among our hundreds.
• All querying takes place against that locally cached mirror, so there are no performance issues once the mirror is built.

At some point we may also drill into the plugin readme file and require that there be a changelog entry for the update in order to actually run the update (again, our team does better when our tools require us to follow best practices)

I definitely read through your plugin, and also WP Pusher, to get a sense of what hooks were available. How the hell did you figure that out? There are some really obscure hooks going on. At many other times, I was working totally independently, and later found that I'd reached a similar tactic to what your plugin does. And at many other times, things just ended up being different, for better or worse.

I owe you and your team a huge thanks.

We're not using it in production just yet, but we're close. I'm going to write a test suite for it, and then we're planning to start using it.

[afragen]

The GHU plugin should only really take a performance hit every 12 hours, otherwise everything is cached. Also, that only happens for admin users on specific pages.

Are you speaking about my hooks or those in WP Pusher? I found mine by a lot of googling and prior art.

Does WP Pusher not serve your needs? @petersuhm has done great work with @WP_Pusher and I think it's probably a much better solution for you. Once set up on the site you should get push to deploy. After the initial setup of the WP Pusher plugin I think that's all. Peter is actively improving WP Pusher and it's a very well done and respected solution.

BTW, I have no team, just me and anyone willing to help. :wink:

I'm always interested in how others solve the same issue. Can you post a link back to your solution here? Thanks.

[afragen]

I'm curious. I was just thinking that perhaps a companion plugin to GHU that allows for the incorporation from a JSON config file to insert plugins/themes that don't have the proper header.

Essentially it would add this data via a filter that could be placed in GHU. In this way it might be possible to add plugins/themes to GHU for updating even if they don't have the proper headers.

The dev would just need to add a properly composed JSON file to the companion plugin and install and activate the companion plugin, though this could be easily done within GHU's Install.

Does that sound interesting or useful?

[scofennell]

I haven't worked with WP Pusher much, personally. I have some teammates who are quite familiar with it and they still persisted in commissioning me to write our solution, so I can only assume there was some issue with it that made it problematic for us.

When it comes to themes and plugins, we tend to have better luck making our own tools that fit us perfectly. It ends up saving us time/money in the long run and keeps our developers growing on challenging but attainable tasks.

Either way, I think push to deploy sounds like a bad idea for us. Doing things from the normal wp-admin dashboard is much easier in our situation, as we're often okay having our front-line support folks run plugin updates in wp-admin, but we're not going to have those folks in the command line doing a git push to deploy. The idea in our case, is that a developer would write the update, push it to master, and update it via my plugin on an appropriate sample-size of our production installs. After that, our less technical folks would be clear to update it on their per-client installs, also via my plugin in wp-admin.

I'm able to share snippets on specific points of interest (got any? I'll gist 'em right now for you) but I don't think I'll be able to share the entire plugin in the public sphere. For one, it has our Bitbucket creds hard-wired into it. If I sanitize them and pass it on to you, that might be okay. I'll check on that next week for sure and respond here.

=== Edit, to your question about JSON ===

I'm not sure I appreciate the need for the file headers at all, no matter how they're passed in. What I'm doing in my version is just looping through all the repos in the BB account, and flagging which ones are themes/plugins, updated/outdated, installed/uninstalled, as I go. No file header stuff, other than the version number, which, again, is a requirement we like having, so that we are forced to version our work properly.

Thanks again!

[petersuhm]

@scofennell, after briefly skimming this, it sounds like WP Pusher might be an option, because we don't use headers. Let me know if you need me to clarify anything or need a demo! (peter@wppusher.com)

[scofennell]

Hey @petersuhm, thank you for the response. It's great that you don't use headers and I'm not exactly sure why we declined to use WPPusher, but regardless, our in-house plugin is looking really promising.

@afragen, my CTO has agreed with me that we should definitely share this with you. If you could give me an email address, I'd be happy to grab a version without our BB login creds, and zip it over to you.

[afragen]

My email is andy@thefragens.com

If ( https://github.com/scofennell/bucketpress ) it does include some credentials. You really should change them.

[scofennell]

Nah, that repo you found was my early efforts, before my employer decided to pick up this project, and the BB creds there are to a junk account. Deleted just now for good measure though, thanks for pointing that out.

Anyways, cool, email sent.

[afragen]

Thanks :wink: