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
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.
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.
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.
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.
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.