inherit
264279
0
Feb 5, 2024 17:01:15 GMT -8
shawnatdgk
59
May 2021
shawnatdgk
|
Post by shawnatdgk on Jun 19, 2023 16:03:39 GMT -8
So I know back in the day, one couldn't get elements or html of anything from a page if the code wasn't in that pages headers and footers. Something to do with privacy. Just curious, is this still the case?
For example, if a person wanted to display recent posts on the Home page. Not saying this is what I'm wanting to do, but "for example".
Thanks
|
|
Kami
Forum Cat
Posts: 40,201
Mini-Profile Theme: Kami's Mini-Profile
#f35f71
156500
0
Offline
Jul 24, 2021 11:48:29 GMT -8
Kami
40,201
July 2010
kamiyakaoru
Kami's Mini-Profile
|
Post by Kami on Jun 19, 2023 18:01:13 GMT -8
So I know back in the day, one couldn't get elements or html of anything from a page if the code wasn't in that pages headers and footers. Something to do with privacy.Just curious, is this still the case? For example, if a person wanted to display recent posts on the Home page. Not saying this is what I'm wanting to do, but "for example". Thanks There isn't a privacy issue from the specific use case you're describing (at least, not that I am aware of), but we are limited when modding pb forums by a few major things: a) that javascript can only access content on the page after it loads, and b) plugins cannot make automatic requests to the servers, and c) pb forums are designed to break out of any iframes. In the specific example, you wouldn't totally be able to do that because not *all* recent post information is available for a script to pull; however you can use the "recept posts in sidebar" plugin to get a smattering of content (does not update if posts are made via mobile or when javascript is turned off), or set the home page to be the recent posts page instead of the forum. As far as I know -- and someone more versed in plug-in authorship may correct me -- your only real limitations for pulling content comes from not being able to send requests automatically & being unable to pull content if it doesn't exist on the page.
|
|
inherit
264279
0
Feb 5, 2024 17:01:15 GMT -8
shawnatdgk
59
May 2021
shawnatdgk
|
Post by shawnatdgk on Jun 22, 2023 7:39:57 GMT -8
Thank you for your response. I follow what you're saying for the most part, but please elaborate on what you mean by "not being able to send requests automatically" and "plugins cannot make automatic requests to the server" if you will be so kind for a little more of your time please and thanks again
|
|
inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,018
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Jun 22, 2023 8:30:27 GMT -8
Prohibitied Code List:Prohibited codes are either not endorsed by ProBoards, may not work properly with our software, and/or may be a violation of the TOS/Developer Guidelines. The following types of codes are prohibited: - Codes that display information on an external site.
- Codes that stop members deleting themselves.
- Codes for automatically deleting members.
- Codes that give others access to the security log.
- Codes for anything that would be an invasion of privacy.
- Codes for extra options before registering.
- Codes that make requests to ProBoards' servers except through methods explicitly allowed for by ProBoards (such as plugin set() functions). Examples of prohibited codes include using ‹iframe› tags to access forum content, or making AJAX requests to ProBoards forums.
- Codes that affect the placement of advertisements on any ProBoards forum, except those specifically authorized by ProBoards.
- Codes which cause automatic redirects on page load to a new URL or automatic refreshes.
- Codes which rely on external code to work properly. Note that using external data is acceptable, so long as that data is loaded asynchronously.
- Codes which use plugin keys to store unrelated data, e.g., sharing a single plugin key between multiple unrelated plugins.
ProBoards reserves the right to reject any code which may adversely affect the user experience or interfere with the operation of its software. This message is for ProBoards Developers that are creating plugins We have not yet released our full developer guides, but there is one important point that I would like to make in case it impacts anyone while you work on plugins. With Plugin Keys, you have the ability to get and store information on the ProBoards servers. Every time you set() a value on a key this will trigger an AJAX call to our server. Because of this, there is one important restriction that plugin authors must adhere to when creating a plugin: You can only set() a value on a plugin key based on a user initiated action. For example, a user clicking on a button which triggers a set() call is acceptable. Automatically triggering a set() call with no user interaction, though, is prohibited. Example of acceptable plugin:You want to create a plugin to track how many people +1 a topic. You create a thread key, and have a button users can click to +1 the topic. When the user clicks the button, you call the plugin key's set() function which triggers the AJAX call. Example of a prohibited plugin:You want to count how many pageviews a user has on a forum. Every time a page is loaded, you automatically call set() on a user plugin key to increment a count.
I hope this is clear. If you have any questions, please ask. If it's still a user initiated click, you can move items out of the dropdown into the post if you want. Since the user already has access to the report post option, moving it out is not a problem. As long as it's a user-triggered action (e.g., not automatic on page load), you could duplicate the AJAX call and show the dialog. All you need are the thread ID and CSRF token, and you should be able to call it.
|
|