adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details

I would like to take this bug, if possible.

I wanted to ask, how can one read rc files.
Thank you.

(In reply to comment #4)
> I wanted to ask, how can one read rc files.

rtl/bootstrap.hxx

still working on this issue?

Unassign due to lack of work.

Please remark, if you start working on the issue again, feel free to assign it to yourself.

Resetting status.

Hey
I would like to contribute to fix this bug. Is it still open ?
Is there any specific code pointers that should start

(In reply to Asela from comment #11)
> Hey
> I would like to contribute to fix this bug. Is it still open ?
> Is there any specific code pointers that should start

Welcome, follow comment #1

And also have a look at 
https://wiki.documentfoundation.org/Development/GetInvolved

have fun

(In reply to Björn Michaelsen from comment #0)
> Remove hard-coded project URLs
> 
> Background: We still have a number of hardcoded URLs around the place, some
> of which become visible in the UI. We should have these extracted from a
> config file instead - preferably a textual 'rc' file (sal has code to parse
> and use these cf. boots). To find many instances of hard-coded URLs use:
> 
> bin/g grep '"http://' | grep '\.[ch]xx:'
> 
> or grep for libreoffice.org - BEWARE - many instances of openoffice.org are
> standards related around ODF and other XML file formats - these must -not-
> be changed (obviously). But ones that point to simple web pages make good
> targets for clean configurability.
> 
> Skills: git grep, simple C++ programming

Could you explain what "...and use these cf. boots..." means?

(In reply to adityapratapsingh51 from comment #13)
> Could you explain what "...and use these cf. boots..." means?

cf. means comparison. Note comment 5

wow more than 4 years!

someone still working on this?

by "..around the place.." meaning most source files still have hardcoded URLs??

(In reply to rino19ny from comment #15)
> wow more than 4 years!
> 
> someone still working on this?
> 
> by "..around the place.." meaning most source files still have hardcoded
> URLs??

Please don't change the status to needinfo: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO
Needinfo reports will be automatically closed after some time, so you don't want to do that here.

Basically I have to create a .rc file which contains all the URLs and somehow read it with help of bootstrap.hxx at runtime 
But I am confused on the following points:

1) grep for libreoffice.org - BEWARE - many instances of openoffice.org are standards related around ODF and other XML file formats - these must -not- be changed (obviously). But ones that point to simple web pages make good targets for clean configurability. 

I don't understand what you are trying to say, can you explain with example?

(In reply to Padia Rashesh from comment #17)
> Basically I have to create a .rc file which contains all the URLs and
> somehow read it with help of bootstrap.hxx at runtime 
> But I am confused on the following points:
> 
> 1) grep for libreoffice.org - BEWARE - many instances of openoffice.org are
> standards related around ODF and other XML file formats - these must -not-
> be changed (obviously). But ones that point to simple web pages make good
> targets for clean configurability. 
> 
> I don't understand what you are trying to say, can you explain with example?

Example of such a search hit, pointing to an XML namespace:
UnoControls/util/ctl.component:    xmlns="http://openoffice.org/2010/uno-components">

(In reply to Björn Michaelsen from comment #0)
> Background: We still have a number of hardcoded URLs around the place, some
> of which become visible in the UI. We should have these extracted from a
> config file instead - preferably a textual 'rc' file (sal has code to parse
> and use these cf. boots).

Note that many such URLs are now stored in the configuration, see properties "SendFeedbackURL" etc. in officecfg/registry/data/org/openoffice/Office/Common.xcu.  That's probably the preferred way now.

Dear  Padia Rashesh,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assign it back to yourself if you're still working on this.

Re-evaluating the EasyHack in 2022

This enhancement is still relevant. Some hard-coded project URLs are still in the code.

(In reply to Stephan Bergmann from comment #19)
> (In reply to Björn Michaelsen from comment #0)
> > Background: We still have a number of hardcoded URLs around the place, some
> > of which become visible in the UI. We should have these extracted from a
> > config file instead - preferably a textual 'rc' file (sal has code to parse
> > and use these cf. boots).
> 
> Note that many such URLs are now stored in the configuration, see properties
> "SendFeedbackURL" etc. in
> officecfg/registry/data/org/openoffice/Office/Common.xcu.  That's probably
> the preferred way now.

I am currently working on this bug and have made some progress. I have moved the URLs to the Common.xcu files and modify neccessary CPPUnitTest files, running make was successful bug I am getting an error from make check. 
Something of this nature:
[_RUN_____] testImageHyperlink::TestBody
image-hyperlink.docx:
/home/samuel/Documents/Dev/libreoffice/sw/qa/extras/ooxmlimport/ooxmlimport.cxx:82:testImageHyperlink::TestBody
equality assertion failed
- Expected: https://libreoffice.org/
- Actual  : http://www.libreoffice.org/

The fail I Saw came in from ww8export3.cxx because it has a block of code in there:

DECLARE_WW8EXPORT_TEST(testHyperLinkURLSaving, "tdf120003.doc")
{
    OUString URL = getProperty<OUString>(getShape(1), "HyperLinkURL");
    // Without the fix in place, this test would have failed with
    // - Expected: https://www.libreoffice.org/
    // - Actual  : tps://www.libreoffice.org/
    CPPUNIT_ASSERT_EQUAL(OUString("https://www.libreoffice.org/"), URL);
}

(In reply to Adoche Onaji from comment #23)
> The fail I Saw came in from ww8export3.cxx because it has a block of code in
> there:
> 
> DECLARE_WW8EXPORT_TEST(testHyperLinkURLSaving, "tdf120003.doc")
> {
>     OUString URL = getProperty<OUString>(getShape(1), "HyperLinkURL");
>     // Without the fix in place, this test would have failed with
>     // - Expected: https://www.libreoffice.org/
>     // - Actual  : tps://www.libreoffice.org/
>     CPPUNIT_ASSERT_EQUAL(OUString("https://www.libreoffice.org/"), URL);
> }

This is about https://gerrit.libreoffice.org/c/core/+/142005

Undo your changes in the test (qa) directories. The use of www.libreoffice.org URLs there is just a coincidence and not relevant for this hack.

So undo like

git checkout master -- sw/qa/extras/odfexport/odfexport2.cxx

for each file and update your patch.

Adoche Onaji committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b1dc8d302f5a7c7b8f69261f86ff01377a910c68

tdf#38890 Remove hard-coded URLs in source Files

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Per the comment at <https://gerrit.libreoffice.org/c/core/+/149115/3#message-6567492764d8ee5a399865e62ff490863b2625e1> "tdf#38890 Remove hard-coded URLs in source Files":  "So about this bug 149115: tdf#38890 Remove hard-coded URLs in source Files | https://gerrit.libreoffice.org/c/core/+/149115, are there no more hardcoded urls in the source, after grep libreoffice, most outputs are instances of open office or comments or Test codes"

And I also hardly find anything that looks like it could be another target for this easyHack when I search now, so lets leave it at that.