Beta 22 - Text Component Issue

@dan

In the past, double clicking in the text component would then enable editing in the text component.

In Beta 22, if you double click in an empty portion of the component, nothing happens. If you double click on text in the text component then it works and you can edit the text.

On another note, Select All, Copy, and Paste are all working again, but Shift-Click is not. Shift-Click exits editing and selects the Text Component itself

1 Like

Hi @dan
Iā€™m also seeing on the @Text component, when assigning a link, the pageId is not showing the correct page path, looks like it is still using the original default page name, instead of what was set on the page in itā€™s Folder & Filename.

Hmm, Iā€™m not seeing that here :thinking: Can you share a sample project that shows the issue? (will make it much quicker to fix)

Hereā€™s a file, look in the Debug log and pageID:

File Link

Hereā€™s a screenshot, just in case:

If PageID isnā€™t a url, then we definitely need a url attribute in there for the link :wink: Thanks.

No bug here. Thatā€™s the unique ID for the page youā€™re linking too, not the actual url/link.

UPDATE: btw. You can get any page properties you need, take a look at the ā€œPageā€ custom component to get you started. Also See; rw.page Docs.

Hi @Bill,

Iā€™ve just noticed in your test project that youā€™re extracting and logging the mytext property in the hooks file. These values use an internal type and should not be processed in any way. The format can and most likely will change over time.

There are two supported ways to obtain a valid link to another page/resource. Using a link property, or, as Dan said, using the rw.pages property in the hooks file.

Cheers

Change is fine, as a matter of fact hereā€™s a good change, you already pull anchor when setting a link property, just give us the relative url and be done with it. Thereā€™s no way in your api for us to get that link, you guys have to provide that.

Iā€™m not entirely sure what youā€™re trying to achieve here ā€” could you provide a sample project or a more detailed explanation of where/how you would like to access relative URL?

It would really help me if you could describe the exact issue youā€™re encountering. With more context, Iā€™d be happy to explore potential solutions or suggest an alternative approach.

@tpbradley Itā€™s very simple, when someone is using the @text and sets a Link using the ā€˜Pageā€™ selection, I need the relative path from the current page to the page that is selected, easiest to put it in a property inside of link, where my screenshot above shows.

Th real question isā€¦ why are you trying to extract a link from a @text block?

Shhhhhhhā€¦ Itā€™s a secret :speak_no_evil:   I think I have a solution figured out :partying_face:

Hi Bill,

I appreciate youā€™d like to keep things under wrap while youā€™re working on it. However, I feel I should again highlight that parsing the raw data from @text or @typography within the hooks file is not supported or allowed.

If a component is found to be doing this Iā€™m afraid it wonā€™t be allowed onto the store for distribution. The reason for this is quite simple. In the future (possibly years down the line) I can almost guarantee that the text data structure will change. Any add-ons parsing the current data format will almost certainly break leaving us with a lot of unhappy customers.

This has happened time and time again with RapidWeaver Classic where developers have used undocumented APIā€™s. We really want to avoid this as itā€™s detrimental to users, developers and the platform as a whole.

Weā€™ve started to put together some guildlines for building add-ons, you can find it here

That said, Iā€™m excited to see what youā€™re cooking up. If you do need to parse the raw text data for any reason, please tell us your use case. You can message us privately if you prefer.

Cheers
Tom

This! The forums were filled with these types of issues. The better solution is to use the tools provided OR in confidentiality, request a need that can be addressed in the proper API. I fully support this.