@JoomliC this seems to work.

One thing i notice. If we do this static xml reference approach everytime the core adds a new component, module, plugin, etc we need to add it here.

A dynamic tree search for xml files would be my prefered method.
Similiar was done in the update sites rebuild process.
Maybe reuse it somehow?
See https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/models/updatesites.php#L231-L262

@andrepereiradasilva i thought of this first, but then, if someone runs bump version with third party extensions installed (for example com_patchtester), it will bump version for those not core extensions too...
But not sure here of the best way to go...

bump.php is just for joomla cms - no third party.

Right. I don't know about others, but in my main CMS clone I often have other extensions installed for testing and do a terrible job uninstalling them when resetting (you should see my .git/info/exclude file...). It's why I had to do a second CMS clone when I was doing releases so that I had a pure environment to work from.

On the one hand, those running the bump script probably should be doing it in a pure environment or know the consequences of running it with extra extensions if it is just scanning the full directories and making changes without considering core/non-core state whereas the static list is in some ways "safer".

On the one hand, those running the bump script probably should be doing it in a pure environment or know the consequences of running it with extra extensions if it is just scanning the full directories and making changes without considering core/non-core state whereas the static list is in some ways "safer".

I agree with this (even if not better in code maintenance, safer for end user).
In the same time, we don't add new extension in core every day! (so maybe not a big deal)

In case it's requested to have a dynamic manifests list, similar to updateSites rebuild(), i have code ready ;-)

@andrepereiradasilva in the same time, the fact to not include some extensions in core, will need a maintenance too to exclude them in a loop function to generate list ;-)
The static list seems safer... ;-)

Suggest to fix the problem at the root. The #__extensions is missing a column to denote it is a Joomla core part. Suggest to add that and use it to determine which xml's to process.
That could be used at any location you need to process core parts.

That requires rewriting the script to boot up enough of Joomla to pull database information; this script is usable without that (you could even run it on a CI environment without a Joomla install if you really wanted). I wouldn't add that column to the database and rewrite the script just for this use case, especially considering it's a script that never gets released to users (and let's be honest, who beyond myself, George, or whomever is doing releases at the time might use it?).

And there already is such a column in the database though its use is debatable and unclear; the protected column which is suppose to denote extensions you can't uninstall as that would fatally destroy the application. Yes, I'm fully aware there are extensions that can be uninstalled and when updates happen later they choke because the extensions aren't there, but that's because the updater (specifically the schema manager) is a hunk of crap. From my perspective, it's better to keep going with modularization and make the schema manager smarter than to make com_contact a protected extension.

/off-topic-ranting

Agree with your first argument, was triggered by yet another occurrence of trying to find core extensions. Didn't see it wasn't for part of Joomla.

Disagree with your second argument. The column protected doesn't qualify as a setting to denote as part of core. Part of core and required by core are two different things. Probably shouldn't even call it part of core, with extensions like weblinks should probably call it maintained by core. It is considered bad database design to combine things.

For me core is "what can't you remove because it'll screw stuff up", not "this is included in the package you get from joomla.org", so I'd say protected serves a purpose at that level. If you want to get into the latter part of that, scan the database for extension ID < 10000 and call it a day. In the long run I don't think the database needs a special flag for "extensions maintained and distributed by Joomla, be it as part of the package from joomla.org or a standalone thing like weblinks".

Wouldn't base the solution on yet another mistake: ID < 10000. Suggest to consult someone experienced in Data modelling and Normalisation, apparently not your forté.

Ya, it's not something I specialize in, but for a quick fix with a known data set that absolutely does the trick. I still don't see why in general there needs to be a special flag indicating a core extension, especially considering any flag that's added to the API is just as easily misused by third party folks (I'm sure you've seen posts on the forum where people groan about stuff being marked protected).

Tricks only work till the bugs they depend on are fixed.
Indeed, have seen those posts. Makes you wonder about its implementation. With the flag for core extension you could have limited the protected setting to core extensions. Ignoring the setting for non-core extensions. That won't stop abuse, but considering the open source nature, there is nothing you can do about that.
Convinced that people will recognize bad behaviour of extension builders and stop using them.
The fact anything you do can be abused shouldn't stop you from doing the right thing.
The fact the update also requires a list of core extensions proves the requirement exists. Using a static list needing to be maintained is reason enough for including it.

Agree something to find core extensions is good. I still don't think
database fields or attributes in the XML manifests are the right way to go
about it but honestly there aren't many other options either. At the end
of the day it needs to be harder for an extension to mark itself as core or
protected than an UPDATE query.

On Sunday, May 29, 2016, sovainfo notifications@github.com wrote:

Tricks only work till the bugs they depend on are fixed.
Indeed, have seen those posts. Makes you wonder about its implementation.
With the flag for core extension you could have limited the protected
setting to core extensions. Ignoring the setting for non-core extensions.
That won't stop abuse, but considering the open source nature, there is
nothing you can do about that.
Convinced that people will recognize bad behaviour of extension builders
and stop using them.
The fact anything you do can be abused shouldn't stop you from doing the
right thing.
The fact the update also requires a list of core extensions proves the
requirement exists. Using a static list needing to be maintained is reason
enough for including it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10665 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAWfoTjxOF2-S9l7H52bA-AaA3LAgiurks5qGeDCgaJpZM4IpR8T
.

I still don't think database fields or attributes in the XML manifests are the right way to go about it but honestly there aren't many other options either.

At the end of the day it needs to be harder for an extension to mark itself as core or protected than an UPDATE query.

Just an idea, but you could have a xml file with a list of core extensions (type and id) somewhere and use it when needed.
Something like this:

<coreextensions>
    <coreextension type="component" id="com_content" />
    <coreextension type="plugin" id="plg_system_redirect" />
    [...]
</coreextensions>

Only modifying this xml would change what joomla cms designates a core extension.

Good idea, include the file in updates and fail the update, unpublish extensions when #__extensions doesn't match file. Remove those extensions from JED, add them to a blacklist and deny installation of them. Publish them on joomla.org as blacklisted. Include them in that same file as core extensions.
Change the drivers to disallow updating that column.

Not full proof, but what is?

ok, IMO this PR itself will be with manual reference until some list of core extensions exist.

@JoomliC, will test it better this afternoon.

Used php build/bump.php -v 3.7.1-alpha1

Result (com_admin manifest)

<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="3.1" method="upgrade">
    [...]
    <creationDate>May 2016</creationDate>
    [...]
    <version>3.7.1</version>
    [...]
</extension>

Questions:
1. Note the version="3.1", shouldn't it be version="3.7"?
2. IMHO we should always update the version in the manifests, regardless of the folder modified dates.

1. Note the version="3.1", shouldn't it be version="3.7"?

I would say no, as it is not extension version, but Joomla minimum version on which this one could be installed.

1. IMHO we should always update the version in the manifests, regardless of the folder modified dates.

IMO it's logic to update version only if changes inside the extension files.

In the same time, depending on how this bump is processed, it's possible that the last modified date of a folder is not updated in the same time the inside files are modifed. This could be controlled only on a real test as it is processed today by @wilsonge or @mbabker , with maybe older versions... ?

I would say no, as it is not extension version, but Joomla minimum version on which this one could be installed.

And a core extension can be installed in lower versions...?

And a core extension can be installed in lower versions...?

Many will ! (almost all plugins for example...)
It would be lost of time to test lowest CMS compatibility (and a bit of a stupid job!) for each extensions! ???? (and crazy!)
This is for me not to be changed, and could be the first version it was added (3.1, 3.2, 3.6 (if new ext. added in 3.6) etc...) and until the minimum required changes (eg. for 4.0).
But this number is not related to the extension versioning itself so not related to this PR ;-)

technically probably yes although I dont care at all about anything to do
with installing a new version on an unsupported version of joomla

On 30 May 2016 at 18:20, andrepereiradasilva notifications@github.com
wrote:

I would say no, as it is not extension version, but Joomla minimum version
on which this one could be installed.

And a core extension can be installed in lower versions...?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10665 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPH8WJFUdFjs-2DAGx3i2vWN1ILUIzuks5qGxxDgaJpZM4IpR8T
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

i see no problem with changing, but i also see no problem with no changing so ok.

I have tested this item ✅ successfully on 78d529d

@andrepereiradasilva I cant tell if you have tested this and its ok and can be moved to RTC or not ;)

no, didn't test it

Looking at this again I dont agree with changing the creation date and version number automatically - if nothing has changed then why would you change it - that just seems plain wrong to me

@wilsonge @rdeutz can we have a decision on this one please

we have to rethink the whole process don't think this here is the way to go, closing

Looking at this again I dont agree with changing the creation date and version number automatically - if nothing has changed then why would you change it - that just seems plain wrong to me

Hi @brianteeman the process here is checking if any file modified before to bump the version : https://github.com/joomla/joomla-cms/pull/10665/files#diff-c6926ab6dff49e764babf45abbda3d6eR356

we have to rethink the whole process don't think this here is the way to go, closing
Ok @rdeutz !

I still think that when a core extension is updated, the version should be bumped for clarity ;-)