Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem update libraries folder if this path folder redefined in JPATH_LIBRARIES via custom defined.php #7346

Closed
remotehelp opened this issue Jul 5, 2015 · 8 comments

Comments

@remotehelp
Copy link

EXAMPLE PROBLEM:

  1. my home dir /var/www/public_html/ and usal full path to libraries folder /var/www/public_html/libraries
  2. I move libraries folder to /var/www/.libraries and defined this path in JPATH_LIBRARIES in custom defined.php
  3. after download and install update package Joomla_3.4.x_to_3.4.3-Stable-Patch_Package.zip through "Extension manager" I find libraries folder in my home directory /var/www/public_html/libraries and my version in administrator panel still 4.3.1

then I understand that my custom path /var/www/.libraries not updated and then I must run "\cp -R /var/www/public_html/libraries/* /var/www/.libraries/" and "rm -rf /var/www/public_html/libraries".

@brianteeman
Copy link
Contributor

I would expect that as you have moved the libraries to a non standard lcoation


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7346.

@remotehelp
Copy link
Author

I would expect that as you have moved the libraries to a non standard lcoation

brianteeman - you're a genius

@Bakual
Copy link
Contributor

Bakual commented Jul 5, 2015

Agreed with Brian. What you did is not an officially supported feature. Thus I don't expect it to work through updates and even regular functions of the core may be broken.
Closing as expected behavior.

@Bakual Bakual closed this as completed Jul 5, 2015
@remotehelp
Copy link
Author

JPATH_LIBRARIES in custom defined.php

Bakual - is not an officially supported feature

??? That's so the news!...

@mbabker
Copy link
Contributor

mbabker commented Jul 6, 2015

It's one of those edge cases where you can probably make parts of it work but other parts just won't. Update unpacking is one of those places it doesn't work. I wouldn't be so quick to call this "unsupported", otherwise the override ability would have never been placed in the boot up sequence, but "fixing" it is something that is going to be more effort than it's worth as long as the Joomla core is updated by the Joomla core as a files extension.

@remotehelp
Copy link
Author

mbabker - Hello friend

Just need in com_installer, or where update process worked, include defined.php and use them with update process.

Obviously, that need an elegant solution, but for this needs brains, work which many do not have the desire.

All easier to close the issue with the formulation: "unsupported feature".

Give me info where update process worked ("com_installer, etc..."), maybe I something and sometime invent for this issue...

@mbabker
Copy link
Contributor

mbabker commented Jul 7, 2015

It isn't that. Joomla is updated as a file extension type (so using JInstallerAdapterFile for processing). A file extension seriously just dumps out the package contents to the directory specified in the extension manifest; it does NOT use or support path constants. Nor should it. Because Joomla is updated using its own extension installation library, it is limited to what it can do based on the adapter's featureset. Inherently, there are two options to improve this:

  • A custom extension adapter which has this "extra" logic
  • Updating Joomla with a proper standalone code base (meaning updates are truly decoupled from the core platform to the extent practical; at a minimum this would include the package extraction and filesystem cleanup functions, in theory this could also include the database migrations by having the standalone code boot up the application framework to hook into that portion of the API)

@remotehelp
Copy link
Author

...I known, that manifest files "it does NOT use or support path constants"...

This similar situation described in my post "The problem with the rights to JComments, when the user is in multiple groups"

Where author JComments answer on problem: "Yes, completely rewrite the entire system of storage and processing of rights" - HORROR!

I decided not to waste time arguing and solve the problem yourself... The problem was solved with five lines of code without "completely rewrite the entire system of storage and processing of rights"! The patch I have not opened to the author, because they are ignorant treated me - after next updating Jcomments, I just apply of my patch.

In connection with such an ignorant attitude of the author of many CMS and plugins for them, to the problems encountered, even possible it will be easier to take Composer, ADOdb, PHPMailer, Twig, Buzz, Guzzle, Imagine, TCPDF, Minify, HybridAuth (etc lib), write custom router and make own CMF/CMS - possible this a better option than wasting time on proving bug? :)

Nevertheless, in which files exactly goes processing update process? Where placed this "own extension installation library" and how their name?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants