The framework was built with developers in mind, but unfortunately nurturing app development and attracting app developers is not really a high priority at all.

I would be fine with this, if it were true. We were told of reusable tools, and got instead models that are really controllers that fight us the instant we step outside the box. We were told we would get a rewrite, an update to a true modern MVC, what we got was an MVVM. We were told that there would be a JSON/REST API for ease of external integration(Nonexistent entirely).

It was built for developers of traditional applications to be able to push a button and have a dev cms do most of the work. It was in no way built with developers, and the things we do with the framework, by request, in mind. Lack of flexibility in the code is a massive issue.

Color me jaded, but I'm really quite tired of fighting 4. The bold statement is not at all in line with the code, and THAT is the point of discussion here really. There's no point to work on marketplace additions or even discussion of it when the framework has become a walled garden.

I'll be reaching out to some of you in the next week or so to get in a private chat with our devs and management. Start compiling a list of specific action items (please don't just say "documentation" -- be specific as to what would be helpful), questions and concerns and you can ask them live. Let's get this sorted out. :)

 

I'll be reaching out to some of you in the next week or so to get in a private chat with our devs and management. Start compiling a list of specific action items (please don't just say "documentation" -- be specific as to what would be helpful), questions and concerns and you can ask them live. Let's get this sorted out. :)

Since I can't be sure whether I would be contacted or not. I would just like to point out my topic here: https://community.invisionpower.com/topic/420801-forum-or-bug-tracker-category-to-propose-code-level-changes/

I'm not sure I would be able to contribute much more at the moment. But that is at least a specific action item I would have on the list. I'll give some more thought and see what else I can come up with though. And then contribute it somewhere later, regardless of whether I'll be contacted or not. 

 

The "marketplace" is not really a marketplace and app discovery is frustratingly difficult in a sea of "mods". Contributors have no real way to effectively build a knowledgebase or momentum around their projects. And ultimately, bugs are determined by if it affects core products.

Yes.

 

• The hook system needs to be revisited, specifically for Theme Hooks. At the moment I am avoiding theme hooks like the plague because attempting to get one to behave as I would like feels like an exercise in futility. It's just not nearly as flexible as it should/could be.
• Too many features are tied to a node -> item -> comment structure. Example: try putting tags on a Content Item that has no container. Just try it. Let me know how that works out for you.

Yes.

  Quote

Part of my own frustration comes from the speed of the release cycles. It sounds funny, one would think we'd be thrilled that IPS keeps releasing new versions so quickly. But some new releases have introduced breaking changes (e.g. check your sitemap extensions, there have been changes to some method signatures).

I understand the frustration there, but I can see IPS's side too. I think the idea is to move to a fast release cycle and ideally get everyone constantly running edge release. The new updater is essential to that. See browser updates, you don't think about them anymore, they just happen. But that's going to fail miserably if they aren't following proper semantic versioning in the process. Changing method signatures burns everything to the ground.

 

It was built for developers of traditional applications to be able to push a button and have a dev cms do most of the work. It was in no way built with developers, and the things we do with the framework, by request, in mind. Lack of flexibility in the code is a massive issue.

Exactly my sentiment. Like Kevin and HeadStand touched on: The framework seems to work well for what IPS is doing and planned and built on it. But you're in a world of hurt if your intention doesn't fit that, and it's not changing because it does what it's supposed to for the core products. As far as I'm concerned, therein lies the crux of the issue.

 

please don't just say "documentation" -- be specific as to what would be helpful

Appreciate the response.

There's a time and a place for this, and this may be neither--and I don't want to seem obtuse--but this is exactly the kind of backwards thinking I'm talking about. Maybe you don't think that way, but you need to. It's your product. Be proactive.

A selection from the 'request documentation' sticky, never addressed: (context in the sticky for each)

1. Parsing/displaying text from an editor - 12/17/2014
2. Determining whether your app meets the requirements for node -> content item -> comment - 12/17/2014
3. An overview of all the options in the Extensions tab - 12/17/2014
4. Creating a hello world widget - 12/17/2014
5. Adding custom CSS / JS - 12/17/2014
6. Table helpers - 12/17/2014
7. Step-by-step 'Hello World' app, covering the app structure and how to use all of the pieces involved - 12/18/2014
8. Error codes convention - 12/19/2014 (and while we're at it, the official code standards and style guide)
9. Any kind of documentation on the theming system - 12/31/2014
10. Interface guidelines - 1/23/2015
11. Complete CSS/JS documentation, somewhere actually accessible - 4/13/2015
12. Using the DB interface - 6/09/2015
13. Distinctions on the new framework vs. 3.x - 6/17/2015

If I were new and interested, I would want a guide explaining how to get started (walk through apps, plugins, themes, the developer center, etc.), actually using each of those (building an app, etc.), a breakdown of the major architecture elements, and then walkthroughs of every notable system class and how to use (and not use) them. I would want a way to get my feet wet and feel it out without investing a lot of time and effort.

Almost everything in system should have a guide associated with it. The DB interface. Tables (and all other helpers). Members. Output. The many content extensions. Etc. This should be obvious stuff. Maybe there isn't much to say beyond what the method headers and comments say, but it needs to be put into words anyway. We don't want to crawl through hundreds of source files, trial-by-fire, trying to figure it all out as we go. Some articles of this sort exist, but a lot are missing. What does exist isn't necessarily the most accessible. This one was copy-pasted from some PDF, and a year later the formatting still hasn't been fixed.

Personally, I don't think chat is necessarily the best medium for this kind of discussion. Good feedback takes time to compile and digest. Group chats tend to be scattered and gloss over the details. Maybe as a follow-up though.

I want to put my 2c in,

Framework

I'll keep this pretty short, the framework gives alot of basic boilerplate methods and etc, A lot of the applications extend and make changes but there is stuff that is happening in the extended classes that would of been very useful to have in core, so we do not have to keep duplicating code as you got to target people who might not have this or that app installed.

I'll give an example calendar extends IPS/DateTime it brings a very useful timezone selection tool that would be useful outside of just a calendar.

Documentation

 

A selection from the 'request documentation' sticky, never addressed: (context in the sticky for each)

1. Parsing/displaying text from an editor - 12/17/2014
2. Determining whether your app meets the requirements for node -> content item -> comment - 12/17/2014
3. An overview of all the options in the Extensions tab - 12/17/2014
4. Creating a hello world widget - 12/17/2014
5. Adding custom CSS / JS - 12/17/2014
6. Table helpers - 12/17/2014
7. Step-by-step 'Hello World' app, covering the app structure and how to use all of the pieces involved - 12/18/2014
8. Error codes convention - 12/19/2014 (and while we're at it, the official code standards and style guide)
9. Any kind of documentation on the theming system - 12/31/2014
10. Interface guidelines - 1/23/2015
11. Complete CSS/JS documentation, somewhere actually accessible - 4/13/2015
12. Using the DB interface - 6/09/2015
13. Distinctions on the new framework vs. 3.x - 6/17/2015

This is one of the key issues for me and why I have not really made anything else for the marketplace as there is alot of stuff I don't understand so even some theory as to why and what is happening would be nice. That list you put together from the sticky pretty much sums up what would be really really helpful for people like me who are only getting into development. 

 

Almost everything in system should have a guide associated with it.

+1 This is why alot of people love frameworks like Laravel and Symfony their docs on each module you could say are very fruitful.

Some changes I posted about include:

 

As already mentioned above in Ryan's post (and I posted in the pinned topic as well) the documentation is completely missing for JS mixins and related things:

The only documentation we have for it is an old blog entry and even then things have changed since it's been posted. Mixins/Advice are a really powerful tool but peoples/devs don't even know they exist without documentation. I know them because I read every blog entry posted about 4.0, but for new developers starting out now and checking only the guides they will never know they exist.

I firstly want to apologize, my last post in this topic came out far more harsh than I intended, had just spent the day fixing a custom plugin for a client for the 5th time in 5 'patch' versions.

I have given this a lot of thought, and I only have 2 things that would help me greatly in avoiding such.

1. Make a concentrated effort to forbid the use of \IPS\Request and \IPS\Member::loggedIn() in models, instead passing such data from the calling code. This will help avoid needing to 'hack in' so close to the core code to do anything outside the box, making it less likely for us to trip up on a change made(when you have to be THAT close to the core, the slightest change is felt). I understand this will take time, and is not suitable for a 'patch' version, but it would be vastly appreciated.

2. As Ryan H. said... adopt a true version schema. I actually understand if you would not wish to take up semantic versioning, nobody cares that Chrome is now v46, but the clients might care if such jumps were made here. That said, please adopt a scheme that forbids changing method signatures or data types without incrementing the 'minor' version. I quite honestly don't care if you push out a dozen 'patch' versions in a month, so long as you don't *make* me care. 

 

I've just spent the better part of 3 weeks trying to wrap my brain around 4.x to code a simple extension to another 4.x app. Once I figured out what was going on I managed to get everything coded in under a day, but the pain of getting there was horrible. Reading this thread I see I'm not alone, and I am feeling better...but if I didn't know Ryan H. and his work I might never have looked here!

Lindy, since you asked, what would have helped me immensely would have been:

1. Clarity that any new application is expected to live in its own new set of tables (prefix_appname_tablename), and is effectively forced not to add columns to another table without falling afoul of the support tool and your supported framework. I hate having to JOIN tables that have a 1:1 relationship with another table on a regular basis, but I don't see a supported alternative at this time. I worry about scalability with this normal form violation.
    
2. Clarifying expectations on database table layout. I ended up fighting the DB schema editor a bit since my "extension table" to another app's table results in a primary key that is the same as another table's primary key, is not named id, and is not auto-incremented. I eventually got what I needed but it wasn't pleasant getting there. Given you force this choice on us (see 1 above) there should be dev center support for "extension" tables, preferably support that allows you to declare your app's table is an extension of some other app's table and supports the PK/FK relationship.
    
3. Documentation of the Db class. I ended up having to read the source to understand arguments and methods, which is all well and good, except when I saw comments that say "Read the examples" and there are no examples. ActiveRecord of course gets you to a certain point, but given point 1 above, when you're subclassing someone else's ActiveRecord to add new fields, you are forced to do ugly tricks to get the JOINs you need on classes, and that can result in some manual DB queries. In fact, your own documentation posting about FileUpload has manual Db queries in the FileStorage extension class...and this is a place where where I would have expected an ActiveRecord like pattern
    
4. Better support for versioning an app/plugin right from the IPS4 Marketplace. You have absolutely everything you need when an app is uploaded to determine its version, and when new versions are released. Why should I have to personally host a php (or other) file that generates the JSON doc announcing a new version? This seems a pretty straightforward thing to add to the Marketplace, and would ensure far better compliance of clients upgrading their apps/hooks promptly while reducing my workload to just uploading a new version to the Marketplace.
    
5. Explanation of the magic naming rules for translatable text strings. For instance it's not explained anywhere that adding _desc to a form field's translatable text label will magically use that text to provide supportive text on the form itself, or that menu__ will be prefixed to whatever you call your admin module.
    
6. Any documentation at all about app modules and what the various options are for. There's nothing there; I had to use "monkey see, monkey do" and trial and error to get it working. Surely there's a better way forward here.

Thanks for the feedback - that's very helpful. I'm going to ask development to review and see where we can improve, either from a documentation standpoint or otherwise. 

 

And it's worse practice to turn your database into a train wreck because every time you want to add a column somewhere you're adding an entire table that links to the members table.

You wouldn't have to do that, though. You'd just add one table and each time you need to do anything related to the members table, add a field to the one table.

All I know is it's sure more convenient when it's added to the members table because then you don't have to do anything to get it, as it's already loaded with the other member data.

I'm just curious after all of this time, if people have settled on mostly having new tables or if many of you still add fields to members.

 

I've just spent the better part of 3 weeks trying to wrap my brain around 4.x to code a simple extension to another 4.x app. Once I figured out what was going on I managed to get everything coded in under a day, but the pain of getting there was horrible. Reading this thread I see I'm not alone, and I am feeling better...but if I didn't know Ryan H. and his work I might never have looked here!

Lindy, since you asked, what would have helped me immensely would have been:

1. Clarity that any new application is expected to live in its own new set of tables (prefix_appname_tablename), and is effectively forced not to add columns to another table without falling afoul of the support tool and your supported framework. I hate having to JOIN tables that have a 1:1 relationship with another table on a regular basis, but I don't see a supported alternative at this time. I worry about scalability with this normal form violation.
    
2. Clarifying expectations on database table layout. I ended up fighting the DB schema editor a bit since my "extension table" to another app's table results in a primary key that is the same as another table's primary key, is not named id, and is not auto-incremented. I eventually got what I needed but it wasn't pleasant getting there. Given you force this choice on us (see 1 above) there should be dev center support for "extension" tables, preferably support that allows you to declare your app's table is an extension of some other app's table and supports the PK/FK relationship.
    
3. Documentation of the Db class. I ended up having to read the source to understand arguments and methods, which is all well and good, except when I saw comments that say "Read the examples" and there are no examples. ActiveRecord of course gets you to a certain point, but given point 1 above, when you're subclassing someone else's ActiveRecord to add new fields, you are forced to do ugly tricks to get the JOINs you need on classes, and that can result in some manual DB queries. In fact, your own documentation posting about FileUpload has manual Db queries in the FileStorage extension class...and this is a place where where I would have expected an ActiveRecord like pattern
    
4. Better support for versioning an app/plugin right from the IPS4 Marketplace. You have absolutely everything you need when an app is uploaded to determine its version, and when new versions are released. Why should I have to personally host a php (or other) file that generates the JSON doc announcing a new version? This seems a pretty straightforward thing to add to the Marketplace, and would ensure far better compliance of clients upgrading their apps/hooks promptly while reducing my workload to just uploading a new version to the Marketplace.
    
5. Explanation of the magic naming rules for translatable text strings. For instance it's not explained anywhere that adding _desc to a form field's translatable text label will magically use that text to provide supportive text on the form itself, or that menu__ will be prefixed to whatever you call your admin module.
    
6. Any documentation at all about app modules and what the various options are for. There's nothing there; I had to use "monkey see, monkey do" and trial and error to get it working. Surely there's a better way forward here.

I had to quote your entire post because this is a nightmare trying to cut out the parts I am not wanting to quote. Someone should try quoting this same post and see if they have the problems I do. I tried at least four times and when I highlight a big chunk of it to get rid of, it cuts THE WRONG PART out, not the part I highlighted.

I just wanted to mention for #5 nowhere is not a correct term, it's just that they explained it in the company blog instead of documentation. For some odd reason a lot of stuff they covered in their blog they never added to documentation.

I also indeed think they need wayyyyyyyyyyyy more documentation than is available now, an article on interacting with the database, as you mentioned, for instance. The 3.x documentation was SO very helpful.

The new architecture of IPS4 could be the reason why the marketplace is lacking of any real offerings for potential customers. Midnight Modding, asking for documentation has been a problem that IPS has never corrected. Some may back me up on this, but documentation on the IPS Community Suite has been nonexistent ever since IPS 3.0 launched and it's something that a lot of customers have continued to demand/request of IPS.

 

The new architecture of IPS4 could be the reason why the marketplace is lacking of any real offerings for potential customers. Midnight Modding, asking for documentation has been a problem that IPS has never corrected. Some may back me up on this, but documentation on the IPS Community Suite has been nonexistent ever since IPS 3.0 launched and it's something that a lot of customers have continued to demand/request of IPS.

BS.

https://community.invisionpower.com/4guides/

 

The new architecture of IPS4 could be the reason why the marketplace is lacking of any real offerings for potential customers. Midnight Modding, asking for documentation has been a problem that IPS has never corrected. Some may back me up on this, but documentation on the IPS Community Suite has been nonexistent ever since IPS 3.0 launched and it's something that a lot of customers have continued to demand/request of IPS.

No. The documentation is lacking, true, but that's definitely not stopping anyone here from developing. Most of us have been working with v4 for months now, and the missing documentation isn't hindering us.

I can't speak for anyone else, but the only reason I've stopped contributing is time. Thank God I have more than enough billable work to keep me busy right now. I just don't have the time to work on unsponsored development projects.

@HeadStand yes, but not everyone wanted to go through as much trial and error as all of you who did early work on it did. All of you admitted a lot of frustration during the process and that it took much longer than it would have if you had the documentation.

Personally, I think documentation for 2.x and 3.x was good and easy, but I did have programmers tell me they thought the documentation was bad even for those versions. I have not made anything for any product other than IPS ones, so I haven't seen how good and bad it is for anything else, but there must be some documentation for something else that is really good for them to feel like 3.x documentation as lacking.

For 4.x, however, good grief, there are probably 500 important things not covered in documentation. I've been so swamped with other things I still haven't gotten around to doing any php for it yet so I can't comment on just how easy or hard that is. That helper file that @Adriano Fariadid is helpful, though.

I'm frustrated up to about here right now. (hand at eye level)

One reason being various internals that are implemented three different ways in three consecutive releases, with no backwards compatibility. Just...ffs.

But more notably: A while back I implemented generic node settings on my AT&P app. It's a great demonstration of the power of the new hook system. Awesome. With a few strategically-placed hooks, I have settings magically added/saved/loaded for every node out there. Took a bit of effort to find the right spots and logic, but I got there. Now I find that sometime since then, IPS changed the homepage to skip the normal node 'constructLoadQuery()' method, and load forums via 'loadIntoMemory()' instead. Short of overwriting that entire method (no), or the database adapter itself (nooo), there is no way of hooking onto that query whatsoever. ??

You can't claim to have an extensible system if you're not considering the consequences of implementation choices, and ways to actually make it extensible, in the course of development.

I'm not expecting this case to change, and any change would be too late for me anyway, so whatever. I'll cache the problem away.

It seems like the development gateway forum is being all but ignored since it was moved and opened anyway. -- I'm not exactly sure how "interact with our development team" is supposed to work on a peer-to-peer basis.

This topic would probably be better named 'Ryan's IPS4 rants' at this point.

You can't dare say anything other than it's handled perfectly, Ryan. Any time I say something could have been handled in a better way, I get 5 people telling me how wrong it is to say anything. Luckily, I didn't start until on version 4.1.12.1 so I can hope I won't run into your issues  of the constant changing that affects compatibility.

 

You can't dare say anything other than it's handled perfectly, Ryan. Any time I say something could have been handled in a better way, I get 5 people telling me how wrong it is to say anything. Luckily, I didn't start until on version 4.1.12.1 so I can hope I won't run into your issues  of the constant changing that affects compatibility.

I don't know about that, people have seemed quite receptive to feedback. A lot of the response I've heard has been people in pretty much the same boat, in one way or another. I haven't been particularly involved lately, but it seems like IPS has a bunch of things moving to try helping us out, and they're receptive to change when it's needed.

Just try to do your homework first and share your thoughts coherently. Sometimes there's a good reason for things being the way they are, sometimes there isn't but they're not going to change. That's the way it goes.

You ain't wrong about the dev forum

 

It seems like the development gateway forum is being all but ignored since it was moved and opened anyway. -- I'm not exactly sure how "interact with our development team" is supposed to work on a peer-to-peer basis.

 

 

You ain't wrong about the dev forum

 

There's too much going on and we realize that. Our new developer portal is nearly done and should be rolled out soon. Our hope is to consolidate resources and provide one area for you to visit to get impacting changes, docs, link to the gateway forum, etc. 

Part of the problem with the gateway forum is it's being used as a dumping ground. Ideally, that forum should be used for questions directly to our developers. Best practices, core inquiries, etc. In a perfect world, the "I'm stuck, anyone have any ideas?" topics would land in dev assistance or contributor chat (and again, I know we have too much going on) at least as a first line of defense. I don't want to imply our time is more valuable than yours and we're not willing to assist, only that there's so many hours in a day and our dev resources are stretched very thin so if there's anything you can do to help reduce traffic flow, it will in turn allow us to help you more efficiently with things you're truly stuck on or need attention at an IPS development level and we can make more frequent sweeps through the area.

Thanks!

 

Ideally, that forum should be used for questions directly to our developers. Best practices, core inquiries, etc.

https://invisionpower.com/forums/topic/430174-ipsparserparsestatic-issue/

https://invisionpower.com/forums/topic/429225-expand-the-contentpostedin-method-to-include-reviews/

https://invisionpower.com/forums/topic/428648-advertisements-extension-settings/

etc.

+ There are many bugs which IPS does not fix when develop apps/plugins.

The very, very simple example. Not fixed

 

I've been rather quiet of late, but  I have to echo newbie above.....

it's been five months waiting for any sort of reply, and the issue core described yet remains...

 

Our new developer portal is nearly done and should be rolled out soon. Our hope is to consolidate resources and provide one area for you to visit to get impacting changes, docs, link to the gateway forum, etc. 

What's the latest news on this? Been three months so would appreciate an update.