Jump to content

Community

Marcher Technologies

+Clients
  • Posts

    17,657
  • Joined

  • Days Won

    98

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Marcher Technologies

  1. I would like to know why you think this is fact? IPS' implementation supports the specification of oEmbed to a tee, even unto the rarely used 'link' response type. So long as a given provider follows the oEmbed specification, which would be a requirement to getting a pull request to be on that list accepted, it is designed in such a way it cannot possibly fail... I would encourage you to review the list of providers linked, it accounts for this by providing programmatic access to the embed domain/pattern list via the 'schemes' array for each provider, in essence, it is giving one all the data needed.
  2. https://github.com/iamcal/oembed/pulls It's not like one can just commit a URL and be on that list.... you have to submit a pull request with your changes, and pull requests appear to be vetted by the maintainer of that repo. The latter is related to the former. Yes, the same list would need be utilized in \IPS\Text\Parser::allowedIFrameBases().
  3. While I agree, I could see the complexities of doing so being large enough, that specifically would probably be saner to leave to third-party modifications. While I can add my specific suggestion as well rather easily, I noticed the fact there is no list of what works and doesn't by default is leading to confusion, which this would relieve, as well as utilizing this provider list allowing additions without updates from IPS, or any kind of mod. As a result I think this would be a good move in the software at default.
  4. Instead of needing to manually add xyz oEmbed provider, wouldn't it be a lot less grief for all involved if it just pulled from the provider list available here(caching the result for reasonable periods, of course)?
  5. By the error, I'd suspect the OP is missing files? Try doing a fresh download from client center and re-upload, the error is basically saying it cannot locate the Output class on disk, or it cannot read the file itself due to permissions. Also check the permissions on the files in the /system/ directory and sub-directories, PHP needs to be able to read and execute them.
  6. Hello, You would need to contact the developer originally made the SSO, or consign another developer to upgrade it. The database structure was not the only thing to change, the code itself is vastly different. This documentation on SSO in 4.x may prove useful:
  7. Because the template engine isn't actually parsing that php, the js thinks it is a javascript function to call, hence the error. This should work: var ar = {expression="json_encode($memberArray)" raw="1"};
  8. Maybe I'm missing the point entirely, but isn't a global block relatively easy with some CSS? [data-role="memberSignature"] .ipsEmbeddedVideo { display: none; }
  9. I've actually been giving this problem a lot of thought already.... there is two sides to the coin, people that want more granular control, and those that want a more global approach instead of needing configure every area individually. Either way, I don't see IPS able to fulfill the needs of both, so I'm going to end up making and releasing something for it, for my own use as well as others. That said, unless someone wants to consign me to make it, customs still will remain a larger priority, so it will take some time to get this finished and on the MP.
  10. Reviewing the code, yeah, it's that it's passing \IPS\core\ProfileFields\PROFILE instead of defaulting to it and letting us pass it there, so that would indeed work.
  11. I've put a release on the MP resolving this issue as well as updating for 4.1.x compatibility and dev packager integration.
  12. There's a topic method on that model for ease of access you can use actually: {$record->topic()->url()}
  13. It seems that feature removal has generated all kinds of confusion. The feature that was removed was the ability to provide a custom image *manually* in the ACP per feed to be used as the article image, or as the first part of the imported post. Actual images embedded in the feed itself will continue to import fine....
  14. SELECT tid, title AS ThreadTitle, last_poster_name, last_post, title_seo, pp_main_photo, starter_name, last_poster_name, forums_topics.posts AS PostCount, CASE WHEN core_sys_lang_words.word_custom IS NULL THEN core_sys_lang_words.word_default ELSE core_sys_lang_words.word_custom END AS ForumTitle FROM forums_topics INNER JOIN core_members ON forums_topics.last_poster_id=core_members.member_id INNER JOIN core_sys_lang_words ON core_members.language=core_sys_lang_words.lang_id AND core_sys_lang_words.word_key=CONCAT('forums_forum_', forums_topics.forum_id) WHERE forum_id NOT IN(29, 31, 27, 30) ORDER BY last_post DESC
  15. >.< I didn't give up. I refuse to get paid for 1 CKE theme when I am in effect making 7 of them, 1 per browser.... it's not nice to realize that is the case, and it's frankly ridiculous in this day and age of browser standardization. I want to note, I am not upset with IPS on this one in any way shape or form, this is CKE silliness in whole. Just explaining the issue.
  16. http://docs.ckeditor.com/#!/guide/skin_sdk_browser_hacks I would like to point out the problem is much of the default cke themes(including mono) not understanding the C in CSS. Every one of them uses the browser hacks 'feature' to completely redefine the CSS(including colors, often using !important tags) per browser, instead of just tweaks for the browser in question as needed. Custom CKE themes follow this trend by example. This makes it quite the pain to work with, and rewriting it to be sane is a daunting task as well. This wasn't really too much of an issue in 3 because you had customized CKE to the point it didn't use it's themes. Now that it does, it's glaringly obvious the CSS of CKE stock is a pain to work with.
  17. On a similar subject, could this method possibly cache the results against repetitive queries made due to calls for profile fields of the same member on the same page? Especially when viewing comments of content items where there is back and forth between a few specific members, this would save several unnecessary queries for data we've already loaded when we are doing something like the above, using a hidden profile field programatically in such areas. I see it already does this for the fields shown via "Display format" config.
  18. Could we get a flag on this method that will allow it to return fields configured with "Member can see?" set to no? Right now, if I want to use such a field programmatically I am *forced* to issue an additional query, the field's value is not obtainable with this method, nor any method in \IPS\Member...
  19. It's actually much worse, for the multi-license user anyway. Instead of one suite you run being compromised, they all are? Oh, and that's not to speak of the marketplace access, including to every mod bought being downloadable, as well as the suite.
  20. ....you do realize how bad of an idea, security-wise, storing your IPS credentials..... *anywhere* on your site is, right?
  21. I would report a bug.... that's what the custom formatting fields state should occur, and that was working as suggested in 4.0.x.
  22. I'd suggest reporting that as a bug(maybe even a ticket)... if only for the fact 3.x allowed it, and that can't be a pretty upgrade 'issue' to have,
  23. .cAuthorPane_info .ipsType_light { color: #525252; } Add the above to the custom.css file in your theme.
  24. {{if in_array( member.member_id, explode(',', $record->field_20) )}}
×
×
  • 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