Jump to content

Community

Marcher Technologies

+Clients
  • Posts

    17,657
  • Joined

  • Days Won

    98

Marcher Technologies last won the day on August 19 2015

Marcher Technologies had the most liked content!

About Marcher Technologies

  • Birthday 05/02/1986

IPS Marketplace

  • Resources Contributor
    Total file submissions: 51

Recent Profile Visitors

126,004 profile views

Marcher Technologies's Achievements

  1. Open the network tab of your browser debug tools via inspect element, and then try the upload, you will be able to see what the server responded with and get more information than the generic -200.
  2. Yes, I am fully aware I can do this by extending the KeyValue form helper class. Every, single, time I want to use something not a text input for the key or value. Can we pass this as an option like 'keyFieldType' and 'valueFieldType', defaulting to Text instead, and pass the field type specific options through to them with something like 'keyFieldOptions' and 'valueFieldOptions' please? For reference, I often use this field with the Stack field type, so such a change would need supported with this field type as well to be of value. For example: $form->add( new \IPS\Helpers\Form\Stack( 'my_setting', $values, true, [ 'stackFieldType' => 'KeyValue', 'keyFieldType' => 'Url', 'valueFieldType' => 'YesNo' ] ) );
  3. Unrelated to the original post, should probably submit a ticket so staff can take a look at your database and see if it's something that needs fixed in the codebase. Please note, I am NOT arguing against this. That tool allows one to select posts across pages of a topic. Please define what it should do if you select a post on page 1, 5, 10, and 15 to delete while viewing page 20, which no longer exists as of deleting those posts. This is the kind of thing that the code has to account for in honoring this request.
  4. It bothered me enough i just hooked it in. If you wanted to add this for your own sanity in developing and testing things, I've attached what i did. cheers. Dev Login As.xml Pretty sure the root cause of it not sticking while IN_DEV is the constant regeneration of the data store, which is entirely intended while IN_DEV.
  5. I'm not sure why, but when developing, ergo IN_DEV = true, the 'log in as' feature lasts not even 2 minutes. This results in a ridiculous amount of time waste when one needs to develop against and test a multitude of access levels and configurations. Is there a constant I can set to a member id to make 'log in as' stay put long term while IN_DEV?
  6. Not precisely what you are after, but close. Fluid view enabled: https://invisioncommunity.com/forums/?forumId=492%2C497%2C406%2C503%2C504%2C238%2C500%2C442%2C431%2C506%2C477%2C320%2C493%2C15 Not remotely true. Every view can be abused and called up within any other view. Just a matter of actually knowing the code well enough to do so. CMS app does this natively, in fact, with custom database views completely outside of the norms called up via the 'pages' view.
  7. Maybe just me, but I have a really difficult time discounting developers' and IT managers' reviews of this service. I would tend to recommend holding braintree at arms distance, and certainly not as the sole payment gateway on any site. It's not a matter of PEBKAC for all, reading through those reviews. They have pulled some quite apparently less than ethical moves since being acquired by Paypal.
  8. Wrong dispatcher would be my guess. You'd want to use the Front dispatcher, not the External, and initiate the member session with \IPS\Session\Front::i(); before calling the dispatcher run. Please note, this is only a guess, and is untested, but it makes logical sense that using the external dispatcher like this would cause widgets to go awry.
  9. It is possible with code in a manual HTML page actually. Much less so with a page builder page. Check against \IPS\Member::loggedIn()->language()->id or if preferring to check against locale strings instead of numbers, \IPS\Member::loggedIn()->language()->short Despite the apparent use of a logged in member object, this works for guests as well due to the way \IPS\Member works. Alternatively, see this post. In 3.x any admin could just add a language string, but that was removed from the core in 4.x, or I would have just said to dump them into the language system to begin with.
  10. { "errorCode": "2S291\/3", "errorMessage": "NO_PERMISSION" } To note, Other calls to endpoints actually listed in the scopes tab for oAuth Client config work: The same for an API Key: Note the missing endpoints in the former's case. I suspect this to be the root cause.
  11. If the method is commented to have @apiclientonly in the docblock, instead of denying only OAuth Access Token use, it denies any use other than API key. This is directly counter the documentation: https://invisioncommunity.com/developers/rest-api?endpoint=core/members/POSTindex On the surface, the problem seems to be that such methods are not actually available to be granted permissions in the scopes selection form in the ACP for Oauth Client Credentials. I can't imagine this is intended given the documentation and code. I would appreciate it if this could be looked into, thank you. It is vastly preferred to use the security superior oauth for such work.
  12. Alternatively, depending on the code, it may be feasible to use a normal HTML pages block instead - they support template logic, which unless you have really complex multi-line php statements involved can do the same things.
  13. In the vein of this: And in the train of thought of avoiding doing this: Can the hunk of code that actually 'follows' and 'unfollows' things in IPS\core\modules\front\system\notifications be abstracted out to actually be on the item/node object, or anywhere it could actually be reused? The above reason is not the first time I have needed to control follow status dynamically, and currently such strays extremely close to a direct copy-past of a large chunk of code that is not desired to be maintained by me, and falls foul of the license agreement.
  14. You need to set required to false on the hidden element, then use the validation callback to validate it manually and conditionally - only when the YesNo is in the desired state. Take a look at an \IPS\Node\Model's form() method for any app you own, they all tend to use this.
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy