[#21189] - [4.0] Fix media path to banners folder
- Fixed in Code Base
- 20 Oct 2019
- Medium
- Build: 4.0-dev
- # 21189
- Diff
- Anu1601CS:path
- Success Hound No violations found. Woof! Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Issue
Try to create a new banner. And select image.
Error. Server internal error.
Summary of Changes
Fix path in URL.
Testing Instructions
Try to create a new banner. And select image.
Expected result
Actual result
Error
Documentation Changes Required
NO
This PR is now shown in Issue Tracker, but as Issue, not as PR.
| Category | ⇒ | com_banners |
| Status | New | ⇒ | Discussion |
joomla-cms-bot
- | Category | com_banners | ⇒ | Layout |
Ups, that slipped through my inbox. With the new media storage API, we get now the question if hardcoded paths should still be supported. Because somebody can disable the local adapter and only work with media data from a cloud provider, this will likely crash again. I'm in favor to not support predefined paths as we store now the last opened folder in the local storage of the user anyway. Opinions?
Allon is correct in here, btw as we resolves the URL without adapter prefix even disabling an adapter wont affect articles we use.
About this one need to check whats the url being used to serve the banner, will take a look on pr
Ok Provided solution is not acceptable for me, it uses a hardcoded adapter, even though we provide a method to fetch absolute url to a file, we can get the real url without the adapter prefix.
It need to be done with js like @dgramatikko did with articles
, we can get the real url without the adapter prefix.
As long as it is not an absolute URL ;)
FWIW I didn't do any magic tricks on the other fields, the reality is that the other fields don't use the folder option in the XML. Quite honestly I don't see how some client-side code can help up pick the right adapter. I think there must be a trait with some logic that handles that (some basic checks I guess), or just add one more option to the XML: adapter...
| Labels |
Added:
?
|
||
@Anu1601CS Is this ready to be tested?
| Title |
|
||||||
@Anu1601CS Is this ready to be tested?
This is not perfect fix for this. But, it works for now.
We can open a new issue regarding not to hard code local adapter.
I have tested this item
For me the patch works fine, without any obvious problems.
System:
PHP Build On: Windows NT 10.0 build 18362 (Windows 10) i586
10.1.37-MariaDB
PHP-Version: 7.3.0
Webserver: Apache/2.4.37 (Win32) OpenSSL/1.1.1a PHP/7.3.0
Joomla! Version: Joomla! 4.0.0-alpha12-dev Development [ Amani ] 19-August-2019 13:40 GMT
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21189.
I have tested this item
I followed the instructions provided by @Anu1601CS. Everything worked fine.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21189.
| Status | Discussion | ⇒ | Ready to Commit |
Status "Ready To Commit".
@Anu1601CS Can you please fix the issue in this PR?
@Anu1601CS Can you please fix the issue in this PR?
Ok i will try.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21189.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21189.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21189.
Quy
- | Status | Ready to Commit | ⇒ | Pending |
| Labels |
Added:
?
Removed: ? |
||
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-10-20 14:43:59 |
| Closed_By | ⇒ | laoneo | |
| Labels |
Added:
?
Removed: ? |
||
Thanks!
PR isn't shown at Issue Tracker, so no mark as successfully Test can be done.