I would imagine that this https://github.com/PhilETaylor/joomla-cms/blob/ff54615dbb726c53c3952e09435ab75c590825cc/administrator/components/com_joomlaupdate/restore.php#L6429-L6432 and the associated javascript change mentioned in the comment above would also need to be changed?

Which Javascript? ?

I have no clue :D I just read the comment above that array

well there is no such string as "echoHeadJavascript" in Joomla code so Im thinking this is a copy/paste crap taken over from kickstart?

Since when do edit 3rd party code?

restore.php is part of Joomla Core, it is contributed code, but very much core code!

restore.php is part of Joomla Core, it is contributed code, but very much core code!

restore.php is 3rdparty code.

https://github.com/PhilETaylor/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/restore.php#L1-L11

Well believe what you want to believe. Without this core code it would be impossible to upgrade Joomla the way millions of people do.

This code was contributed to Joomla, is distributed by Joomla, and is maintained by the Joomla project.

@wilsonge Is there not a com_joomlaupdate repo as well? I cant find it here: https://github.com/joomla-extensions

@zero-24 looks like we have a history of making fixes to this file too https://github.com/joomla/joomla-cms/commits/staging/administrator/components/com_joomlaupdate/restore.php

EIther we as a project are forking and taking on the maintenance of this code on our own or we will continue to integrate it as a third party resource the same as all third party resources are. Just because it is used within and distributed with Joomla does not mean Joomla "owns" it. Unless you're now trying to claim that applies to all third party libraries, I hear Symfony protects their trademark pretty well if you really want to go that far.

Well the Joomla project has history of maintaining this file as the history shows:

https://github.com/joomla/joomla-cms/commits/staging/administrator/components/com_joomlaupdate/restore.php

And I'm sure if you demand the original author fix his own bugs I think you will get a nasty surprise...

Im just a lone developer... I hold no positions and make no decisions... thats for someone else...

This particular behavior, while annoying as all can be, isn't a bug in his code. It's really more of an undocumented and undesired behavior for our use case. Yes it probably is something that deserves our attention, but we need to be careful about how many changes we are making to non-Joomla core code (as in anything that is originally sourced from a third-party vendor, including this file).

So is this going to be tested and merged? or shall I just close and delete it ?

@mbabker

So is this going to be tested and merged? or shall I just close and delete it ?

Um. Ahem. Hi. I'm still here. Last time I checked I own the copyright to my code and I didn't sign any paperwork transferring it to the Joomla! Project. Also last time I checked restore.php (properly called Akeeba Restore as you can see in the header) was an integral part of Akeeba Kickstart which is used by millions of people every year to transfer their sites and has a public repository so that other Open Source developers could discuss issues with me and / or submit a pull request. Also last time I checked I was adding features to that code for Joomla!, features which are irrelevant (and useless) to my own software which BTW are 20 LOCs down the line from where you butchered the guts out of that file. Adding ad-hoc changes to that file will only cause pain when you need to update that file.

Regarding the first hunk in this PR, I think you didn't spend much time reading the code or understanding the update process. The initial rename of the .htaccess and other files is a configurable option under the key kickstart.setup.renamefiles. This is something set up by JoomlaupdateModelDefault::createRestorationFile. So instead of butchering the file you could very elegantly edit the model to pass an empty array for that parameter. Simple:)

As for the second hunk in this PR, this is something that if you asked nicely I could very easily integrate in Akeeba Restore as a parameter which would be passed by the Model to disable those automatic renames. It's not a bug in want of a fix, it's a necessary feature for restoring sites which has a side effect when updating sites. I don't understand the derision about fixes, though, and I find it unfair and hurtful. The legitimate bugs you have reported, Phil, were fixed in a matter of hours. Moreover I get to reply to your clients when you CC me on your communication with them, despite the vast majority not being bugs and half of these people not being my paid clients. But I digress. I'm here to help millions of Joomla! users get updates, not psychoanalyze people.

Here's my problem. So far you guys have done ad-hoc changes to that file without caring much to PR upstream. If we tried to update Akeeba Restore I'm sure stuff would break. If someone can PR the relevant changes (@mbabker pretty please?) then I can of course add the missing feature in Akeeba Engine and make a PR back to Joomla! to integrate it to Joomla! Update, fixing the very real issue you are trying to address here. In short, you do the Right Thing(tm), I do the Right Thing(tm), i.e. we do it the Open Source way. IMHO that works much better than accusing each other ;)

Nvm. I backported everything and implemented the feature. Apparently all the work done in 2015 and 2016 to clean up typos was overwritten in October 2016 when we updated restore.php. These are the perils of not making PRs upstream. No worries, I backported these cosmetic fixes too.

Now, do you want me to fix this issue? It's as simple as adding two lines in the model and replacing restore.php with a new version.

Oh, BTW, that "Kickstart crap" you mention is how Joomla! Update talks to Akeeba Restore without going through Joomla! because, you know, while the update is running you cannot run Joomla! (the Joomla! application is in a half-updated state). I am disinclined to rename the configuration parameters for the simple reason that they are used in a lot of my software. This is the kind of change that has a tangible financial impact by means of sunk time and the potential to introduce subtle bugs but also ABSOLUTELY ZERO functional impact in this specific use case (Joomla! Update). Therefore I won't implement it. It's my time and I choose to spend it where it matters, i.e. where it will improve people's lives.

If you would add support for parameters that would be beneficial.