esquire

+Clients
  • Content count

    1,018
  • Joined

  • Last visited

  1. Recover deleted posts,

    Kevin - your app is amazing and worthwhile buying for a million reasons. But in this instance I think that a primary issue is soft deleting individual posts, not topics. And IMHO, I'd not want to have automated deletion (which doesn't have to be set) and it would be nice to have the process work seamlessly. Most of the time I see what appears to be a spammy post and I just hit delete and done. If a user writes to support that we didn't realize it was an erroneous deletion, we simply hit the link, recover the post and done. It's great to have an app as powerful as yours to deal with limitations that we'd like to overcome. Now that what used to be standard is taken out, it seems the question is whether (a) it's feasible to just put it back; or (b) a need to work differently using IPS 4. My concern with choice B is that I know I'll just delete out of a decade of habit and also concurrently using other software that still works the usual way.
  2. Image attachments

    Nice site and well done. Good layout of the photos in the front page like a magazine. My only comments are: (1) This site is NSFW for those following and (2) I think your topmost nav is very difficult to make out the letters, white on light pink background.
  3. Recover deleted posts,

    Because (a) it's no longer in the place where it was for easy reference, context and restoration; and (b) nobody wants to work this hard to create extra visible clutter and clicks when the perfect system was already a part of the core of IPS 3. Too much fixing in IPS 4 that wasn't broken.
  4. Pages URLs Problem

    I don't get why IPS wouldn't use such a system. This is really spectacular. In theory it makes converting from or to IPS 4 seamless and without requiring any 301 redirections. In case anyone is wonder what on earth I mean.... check this out: https://fixxer.com/mag/se/subse/another-lousy-page-i-dont-understand-r4/  >>>>>  https://fixxer.com/4 https://fixxer.com/mag/se/subse/no-photo-here-and-text-is-gone-r5 >>> https://fixxer.com/mag/no-photo-here-and-text-is-gone-5 https://www.yoursitehere.tld/articles/category/subcategory/subcategory/post-name-here-which-can-be-long-r12345/ BECOMES https://www.yoursitehere.tld/articles/post-name-here-which-can-be-long-12345/ The only thing it doesn't do is allow for a dot in the URL like other software we know does (and I hate the way it looks in addition to using them.) This is downright incredible and might actually be the saving grace for the use of IPS 4 Pages. You'll just need to get punished by helping me a bit in making sure the setup is automated properly after obtaining the pro versions. This is darn amazing.
  5. Pages URLs Problem

    This app is insane. I am assuming that you can create a pattern for each module that is in the format: module-name/record-subject-here-12345 so you can get the subject or title of a record and the record number? In summary, this amazing app seems to perform the following: URL shortener for every page Uses the shortened URL as the Link Canonical for both the internal IPS page and the link shortened URL Has a second optional module to automate the above process for every Page you create Adds some overhead overlaying a shortener but response time should be negligible for small to moderate sized sites The truth is that every web page has to have a unique ID. In theory you can have every page just be pulled up using mysite.tld/1 or mysite.tld/2 and then the core FURL interpreter will just store the details of what needs to happen, e.g. use forum module, pull up record 12345. I don't understand why the IPS FURL manager wouldn't either use this system or a uniform application of site.com/database-identifier/record-identifier/ In this fashion the URL would quickly and easily spell out module + record number. Like Wordpress and most systems I use, you can call any record in the database by using either the (1) complete URL with record name in the URL and the record number; or (2) just the record number. So: mysite.com/topic/topic-name-here-12345/ can also be referred to as mysite.com/topic/12345/  This is helpful for 301 redirects should you move to a new system and much preferable to pure text posts. I only learned this later when I tried to wean myself off of Wordpress to discover that having no record ID in the URL made it impossible to have an efficient script for redirection. I looked at the automation app. It's extremely well designed, ridiculously detailed in being able to identify so many tasks and it appears to apply the same record create/update recognition for every app that gets installed. This is probably the only thing that will make using categories work unless IPS can somehow separate the URLs from the taxonomy of content. This is crazy great and should replace the IPS 4 core IMHO, lol. Great work.
  6. I appreciate the clarification on the IPS terminology and logic although I think we are talking about different things. The above describes any typical CMS - three layers - which in simple English conceptually translates to (1) Browse all categories (home page); (2) Browse one category (category page); (3) Browse records in one category (read article). I have no idea why "views" should be in the setup for databases since that's presentation of data in the front end. Thus "views" should have nothing to do with the storing of data. It really should be contained in the "Pages" section, which is supposed to be connecting a database to be viewed at the front end by users. And if you must stick it in the Database section, give it a separate tab called "Views". Baffling UI/UX. Now here is the problem. IPS tackles everything in the Pages module. It's not an article management system, which is probably what 95% or more think it is or will use it to accomplish. It's an Anything Management System. If we're storing widgets like files (or forum conversations like a BBS), that's not so difficult. All you need is (1) browse all categories page (index or forum home), (2) an inner browse one category page for a list of records (listing records or forum display) and (3) a record display page (display one record or a topics / thread page). These displays or "Views" are just display templates. The problem is that IPS provided different displays or "Views" for the top level (index/ home page) but only one View for the second level (listing records or browse one category). The browse widgets view is more simplistic - just list categories and no special treatment needed for records. But with articles, you need to display the records/articles themselves nicely on both the top and intermediate level. It goes without saying that if you've set up the database to show articles (and not widgets) at the top index level, then the display for the intermediate level should match (with an articles View but not widgets. But they didn't. There is only the browse widgets view, not browse articles. And to be honest, I don't know what create a "Page" actually does other than display a database at a specific URL and use the page builder to associate a display at that URL. So if I want the magazine database to show its entry/home page at /mag/, then I define a Page to use the path "mag" and assign a database (the magazine db) to populate that page and drag and drop stuff using the Page Builder. I tried using the different templates in Pages. None of it made any difference - 1 column, 3 columns, whatever. The only thing that did make a difference was go into the database management area and change the index/home/top level View from widgets ("Show record list") to article view ("Show records like articles").
  7. Pages URLs Problem

    LOL. It actually is. It's great work. One last question - let's say I have a Database in Pages that uses Categories, which requires all those categories and subcategories in the URL. Is the IPS core converting the alias to the IPS4 URL and then rendering the page that way? I recall hearing something about the need to store information about a page in the URL when using Categories for a Database. Makes no sense to me as I would think they are independent but have to ask. If it's bypassed, then I can't fathom why anyone would require all that extra stuff in the URL. 
  8. Pages URLs Problem

    So taking an example, if I create a page that has a category URL such as site.com/dbase/cat/subcat/post-name/  - a new url is automatically generated by the plugin. Now when that page gets published, which URL is used - the plugin's URL or the IPS4 Pages internal URL? From what I'm hearing, I'm assuming you're saying that it will use the IPS 4 URL and that the plugin creates an aiias, e.g. site.com/dbase/123-post-name/ as an "alias" to the longer URL. That alias is used as a canonical so that Google will (hopefully) index that alias instead of the URL that is appearing visibly. I'm hoping that it isn't the case since users will copy and use the URL that appears when they pull up a page. So the alternative is that what you mean to say is that the plugin will catch the published page and use the alias every time IPS generates the URL, such as on the home page, in widgets, in RSS feeds,etc. and that it substitutes its own URL every time the real internal IPS4 URL is to be used.
  9. Pages URLs Problem

    Kevin - great series of addons you've got there. I may end up asking you about them as it would seem to require at least a $60 investment per site if this could work (for advanced aliases and automation.) I'd also have to investigate how it works, which it hopefully will. It looks like a great piece of programming and no doubt well worth the money if it can override how Pages works.  If it may benefit others, I'm wondering if a conversation here would work about how one might set things up so that the creation of a standard article could use a different URL, e.g. /database page name/title-of-article-here.1234  (record number in database)  This way when you view articles on the site they will show the aliased URL and that when an http request is made it returns a standard 200 and not redirections. Thanks!
  10. OK... this is extremely frustrating. Apparently filtering still doesn't work on pages to show records like articles as on the main page -- and we're on a year since it was reported in the beta. I mention this because in order to get it to work, I had to convert the articles to look like records - which is the layout you're used to seeing in the forum and what you describe for categories. Allow me to explain the correlation and why this behavior seems to be happening. When you create a database, e.g. Articles to create articles for a news site, you assign it to a page. That page (let's call it the Articles Page) can then be customized at the location you set, e.g. site.com/articles/ - cool. But when it comes to category and subcategory pages, instead of using the layout you selected for the database Page assigned (Articles), they have all of those layout pages use the standard "records layout" format. I can't imagine why they would do this, perhaps because it better fits their documentation which appears to use Pages. I just renewed access intending to use Pages and a couple of other modules for a project. Lots of thought was given in to making it ultra powerful but items like this make it seem that there is still a ways to go until it is finished.
  11. So it does work to some extent. (I still can't figure out how to delete the damn reply box.) https://fixxer.com/articles/ It's not ideal, will require some serious format tweaking, but it's better than just the records. I've also figured out a possible way to defeat the category URL and create "categories" but they can't be nested. I don't know what a feed of articles will look like in half a row but working with it. I can say that Pages is still going to be brutally difficult for the average person to use, even though it's easier than Content was.
  12. Was a joke. I don't understand a number of concepts either moving from 3 to 4. Community but without dedicated community elements.
  13. It's simple and odd that people don't understand. To manage content, use IP.Content. If you want to just manage pages, use Pages. It's not called IP Categories for a good reason.
  14. You mean like this? http://8central.com/
  15. Suggestions unless I'm missing something. I just tried searching the site for a forum on Pages but there is none, similar to the way there is one set up for IPS 3 like IP.Content, IP.Forum, etc. Would this not be a good idea to set up so that questions, support and issues can be easily browsed and searched? I'm getting confused here with one large repository of IPS 4 "stuff" but no ability to separate discussions on each module. In addition a suggestion for consistent treatment of everything (and I wish it was uniform for modules, especially permissions.) It always confuses me to see "Topics" in search. Consistency is really important across the modules. When searching you search a repository. You search "Forum(s)" not topics or threads. You search the Gallery, not "Images." So you wouldn't search the store/Nexus but Products? What if you offer products AND services and other things?