Unfortunately I think it might not be possible to override things in a package (at least I haven't figured out a way). You'll just have to overwrite the model in the package itself and remember to change it again if the package gets updated in the future.

That's a pity. ;-( But thank you for the reply!

Quick question: do you want to override a package's model with a specific model in the root? This should be possible. If you want to override a package's model with a model in another package, or modify a core model with a model in a package, then this is something you can't do. But the first one (which is what it sounds like you want to do, from your forum post) should be possible.

Yes, "I want to override a package's model with a specific model in the root" - but it doesn't work. I try it with the folder structure of the add-on (jshare/models/) and without...

Oh, don't include the package name in the directory. Just copy the exact file found in the package, and copy it to the root. This will cause problems if the name of the filename is the name of another core file, but if it isn't it should be fine.

So if it's packages/jshare/models/model_name.php

you'll copy to

models/model_name.php

I had try it without the folders, too (as I've written ;-), but it doesn't work...

I would update the version of concrete5 running your site. This was fixed in 5.4.1

5.4.2.1 is running...

It worth to take a look at the docs that explain that part you're questioning:http://www.concrete5.org/documentation/developers/system/loading-ob...

Not really actually -- there are so many inconsistencies in the override system (especially in regards to custom templates) and the documentation is incomplete. I run into situations where overrides don't work all the time.

I think it's one of those things that will (hopefully) get slowly fixed over time. I've seen quite a few pull requests on github (and have made one or two myself) related to fixing these inconsistencies in the past few months.

(We just need Andrew to accept them :)

Oh well, but a little documentation is better than no documentation Jordan. You're right regarding the inconsistencies, but they're not under my control and I'm sure the core team is aware of them :)

Regarding the inconsitencies and pull-requests.
I think Andrew has his own quality guidelines and they might not be the same as for the marketplace. Which I think are basic standards compared to what you need to keep an eye for when you commit to the core. I think we both should know it best, because working in open-source projects often results in low quality commits if you don't have some quality assurance or high standards. Accepting every little push-request could look like progress to someone who tries to free a queue, but I think that's the way you can unknowingly inject exploits, bugs, low quality code and inconsistencies. Many opensource projects suffer from such problems. See apache, vsftpd, hadoop.. However assuring quality over a long period of time is very hard compared to working in a local team, I guess Andrew can verify that one. I guess the worst that could happen to c5 is when Microsoft would try to send their backdoor pull-requests ;)


I know you're a very experienced developer and your commits take a high standard, but everyone else can commit too.

Heh... sorry if my message didn't come across the right way. It was kind of an inside joke I guess -- we have a conversation thread going on several pull requests already and I know some are being looked at for inclusion in the next release.

I totally agree with everything you said though, I know it's not the best idea to blindly pull in everything.

Probably shouldn't have bothered with my above comment, it's just that the override inconsistencies are a perpetual thorn in my side on my own projects. (But again I am not laying blame on anyone for this, I know it's a complex system and takes time to work out all the kinks).

Oh, I hope you don't take it so serious because I don't smile in that picture haha :)

Looking at the code for the various override and plugin mechanisms, I see similar patterns of code coming up again and again. Can't help but feel that it could all be abstracted into an override/plugin manager (a helper?), that given a set of folders and a set of priorities for them, returns the one to use (or a prioritised list of all available). Maybe that would help to make it all consistent and facilitate adding override mechanisms where developers kind of expect them but they don't currently exist. Could also use it in packages (there are similar override patterns in eCommerce).