Wolfie

13 hours ago, Matt said:

For example, adding the default option, then adding...

I mean the function to get the default Engine is already in Db.php.  If this will be getting removed with InnoDB becoming a requirement, then this suggestion is moot.

13 hours ago, Matt said:

We have added a lot of code and functionality in the past to allow a variety of hosting environments but we really want to be more firm in what we will support moving forwards.

So does this mean that MyISAM will be losing support (such as in IPS5)?  Again, if so, meaning that InnoDB will be required/forced, then (IMO) it solves the issue anyways.  Would be my preference, to be honest.

6 hours ago, PatrickRQ said:

Is there any risk or any potential loss if I will covert them back to InnoDB?

Always a risk no matter what you do.  It's why backing up the database and files is always recommended before upgrading your community.  So backup your database and then follow @Randy Calvert's advice and do it via SSH if possible.

5 hours ago, Randy Calvert said:

I would PERSONALLY recommend using SSH to do the change instead of phpMyAdmin so that you don't run into any timeout issues.  If the table is small enough though, phpMyAdmin might work.

Agreed.  SSH/console is much MUCH faster and less likely to cause issues.  Any issues encountered are likely ones that would happen anyway.

1. Backup (export) database.

2. Run query to get list of tables using MyISAM, sorted largest to smallest (storage usage).

3. Update very large tables individually, then the rest of the tables in groups.

4. Done.

12 hours ago, Marc Stridgen said:

Are you referring to Members>Administrators here, or Members, then clicking to filter by administrators on the list? I ask as one would be a bug, the other would not

Just for clarifying in case anyone else is wondering or wants confirmation.

So I have constants.php set the ACP session timeout to be over an hour and it's not honoring it.  Was working fine before the .1 release so I have a feeling it may be related to that.

Despite the title, this may not qualify as a bug.

When viewing the members list in the ACP and clicking on the "Administrators" button, there is an account that is showing up twice.  The reason is because it has ACP access via group and because of being added as an admin directly.  Thought I should mention it in case it is deemed to be a bug.  If it's not, then as a feature request, when listing accounts that have ACP access in the Members list, perhaps have an indicator as to why they have the access?  (group vs account)  Then seeing the same account listed twice but with two different reasons would make sense.

4 hours ago, Randy Calvert said:

The server sets the default engine type, not the software. 

I'm aware of that, but I'm not asking for the software to change the server's default setting.  Both MyISAM and InnoDB are supported.  The request is to tell IPS (the suite software) to use a preferred engine if it's supported by the server instead of using the engine labeled as default by the server.  Either that or to always use InnoDB if it's available even if it's not the default.

If you look in the Db.php file, you'll see that it looks for the default engine and then uses that (if one is marked as the default).  The change I'm suggesting is to let the admin choose which to use (such as InnoDB), so long as it's supported by the server.  If not, then it falls back to the default engine.

1 hour ago, Ryan Ashbrook said:

The problem is the two engines are vastly different, and it’s becoming increasingly difficult to support both.

If you know and are allowed to say, will InnoDB be required in a future version of the suite (such as IPS5)?  If so, then that would make this request/suggestion a moot point.

I think there's been a misunderstanding.  I'm all for InnoDB over MyISAM and not the other way around.  The feature request is to allow a community owner to select a preferred engine to use (in my case, InnoDB) if it's supported vs the default engine of the server.  The software does support MyISAM but that's not what I'm asking for.  InnoDB is the preferred/recommended engine (as you have indicated), but some hosts unfortunately don't have it as the default for whatever reason.  Also, there may be situations where a person may prefer an engine that isn't typically recommended (for who knows why), and it would allow them to easily use it.

If nothing else, then defaulting to InnoDB if it's supported before going with the default engine of the server would also work.  It's the recommended one anyway, so why fallback to MyISAM if it's not necessary?

True, but allowing the admin to tell the software what engine they'd prefer it to use (even if it's not the default) is a software related item.  😉

On 6/19/2023 at 7:08 AM, Stuart Silvester said:

If you're getting a blank white page, that's typically a fatal PHP error that the software cannot do anything about or log what's happening. You would need to look at your PHP log for those.

I'm not talking about a white page.  More of the errors that are already presented, but will a tad more information.  App and upgrade step number would do it as it gives the user something extra to include and others may be able to help easier (other IPS clients).  

On 6/19/2023 at 8:57 AM, Marc Stridgen said:

Using a self hosted environment, you should be looking for your host to meet the requirements your software requires, rather than looking for a workaround.

InnoDB isn't a requirement for the IPS Suite though, much less it being the default engine.  It's a simple thing to add with a great benefit, so I'm hoping the devs will at least consider it.

On 6/20/2023 at 4:11 AM, Marc Stridgen said:

Could you please contact the member and ask if there were any issues on signup?

I'm so glad I didn't wager money on it being deliberate with using different i/L switching. 🤣

Bumping this as I think this would be a good option to have.  Could have a warning that it should only be used as a backup (all content), or toggle a switch if there are plans to use on a different site (different members, for example) and then it will filter out certain fields.  Great if you want to share a database and the records, but not share author names (since the user ID's and such won't match up) or the 'post_key' and such.  But if copying from a dev to a live site, might be able to do a full download/upload.

The only real issue I see is with the category ID's.  For the 'field_id' number, the field key could be used so on import, a matching field_key can be found and it get sorted that way.  If no matching one is found, then it reports it as an issue to resolve before the database can be used.  (Import all the records first, then handle the re-assigning of the field_key values.)

Category ID could be tackled by a new SQL column that provides a unique key to each category as it's created and then match it up that way.  MD5 hash of {site's URL}{microtime()} so that it's a key that should never be encountered again.  Continue to use the numerical category ID# (simplicity among other reasons).

Maybe someone could make a 3rd party app to handle it. 😊

11 hours ago, Marc Stridgen said:

I have created a ticket on this for you, so we can take a closer look

So I just got a response on the ticket and it's apparently a known issue that is cookie related.  So looks like I'm not the only one who is affected after all. 😊

Thank you for your assistance.  It looks like I'll just have to wait until the great minds figure it out.

Marc, I forgot to mention that there's some leftover pizza in the fridge if you want to hop back on and grab some.  That's the good news.  The bad news is that I don't remember where it is and it's been over a decade since I last used it, so that pizza is pretty old by now.  🤣

The thing that is bothering me is that no one else seems to be having this issue.  I was hoping it was a bug of some sort, as I hate when something is wrong with just my install.  😠

1 hour ago, Marc Stridgen said:

The admin CP login details added are incorrect unfortunatly. If you are using email to log in, please add that in the username field

Fixed.  So used to a username that it completely slipped my mind. 🤦‍♂️

1 minute ago, Agent Shark said:

A legendary report. I can't wait for the next one 🤪

I imagine the fix for the typo will be to simply remove the deprecated section completely.  Sorry to anyone that it affects!

8 hours ago, Marc Stridgen said:

Could you please update these details

Done.  Fresh passwords, and I even snuck into the dungeon that @Matt is being kept in and gave him some fresh water.  Don't worry, I didn't release him from captivity.

6 hours ago, Marc Stridgen said:

Part of this report is in humor, but is still pointing out actual findings. 😉

If I'm not mistaken, the upgrade process loops through the apps, then within the apps it looks through the individual steps for that app.  So when showing the friendly error (still scary looking but MUCH better than a white page with an error), those two items could be made available.  That's mostly what I'm referring to.  Considering all the different things that happen during an upgrade, it'd be unreasonable to expect specific variables to be displayed based on when an issue arises, though an option to do an export of all variables (only if it can be done to the database for security reasons) wouldn't be a bad thing.  But I imagine that would rarely serve any real purpose, so yeah, mostly just the app and step that it's on.

29 minutes ago, Marc Stridgen said:

"This is a duck" if you really wanted.

I prefer rotisserie chickens.

30 minutes ago, Marc Stridgen said:

It shouldnt actually be possible to register more than once with the same username display name, no

I imagine that if the server is running slow for whatever reason that it could be possible for it to happen, but it'd still be unlikely.  It's why I think the person in question is just being a troll with how they are crafting their display name.  The real question is, are they using the same email address?

Or just open the site in incognito mode (or anonymous/private/whatever your browser calls it).  Accept the cookies.  Click on a link to browse the site.  Click to accept the cookies again.  Click another link or just refresh.  Cookie bar appears again (at least for me).

Just now, Marc Stridgen said:

Please clarify what topic you are referring to there, as this topic is related to logins, which was resolved by patch yesterday.

I think they're referring to the cookie popup issue.

7 minutes ago, SeNioR- said:

False. You cannot register an account with the same display name. Each display name must be unique 👍 The username is created based on display name and cannot be changed.

Usernames are no longer a thing though, at least not in 4.7.  Your options for logging in include email address (recommended), display name, or both, at least for the built-in login method.  So when I said it is a display name and not a username, I wasn't wrong.  The four names shown are all display names, but I bet they're using a combination of lowercase L's and uppercase i's.  Notice there are only four registrations with what appear to be the same name.  That's two available letters being used twice each, so 2^2 = 4.  If they were being used 3 times each, it would be 2^3 (8) possible usernames using a combination of i's and L's.  (Imagine "softie ellla" as being the display name.)

Doing this is actually an old trick that has been used many times, and is actually a trick scammers will use in an attempt to trick people into believing that they are a well known legitimate entity.  I'm sure you can imagine some people would be disappointed to learn that it wasn't "LIONEL RICHIE" that sent them an email saying that they won tickets to see a concert of his, but rather "LIONEI RICHIE" (notice the uppercase "i" instead of an uppercase "L" in his name).

I'm pretty sure that even if someone managed to submit their registration multiple times really fast that only one would succeed.  Once one succeeds in adding the account to the database, the next attempt would find it already exists.  I'm not saying it's impossible, but it is very unlikely.  It's more likely the person did something deliberate by mixing i's and L's to make accounts with similar appearing display names.

8 hours ago, Randy Calvert said:

In my experience the equation is GOOD, FAST, and CHEAP. But you can only pick TWO. 

If I had money to burn, then I'd stick with my current hosting.  It's not a case of wanting to pinch pennies, but a need.  What I picked actually isn't the cheapest, but cheaper than my current and matched enough of my requirements for me to choose them.  There were others that I skipped over completely due to being "too good to be true" or not providing features or options that I wanted.

I already contacted the new hosting provider to ask if they have any plans to change the default to InnoDB since it's recommended, the standard, and the default as of v5.5 (they're on 8.0.33).  So far it's a no.  There is an option I could follow, but I would lose something in the process, so I have to consider a workaround if I go that route.  Of course, if this option gets added, it would solve the problem not only for me, but would also give other community administrators the ability to choose the preferred engine if going with the server default isn't desired for whatever reason.

In the 'init.php' file, found a small typo.  Just thought I would point it out.

// DEPRECATED OPTIONS: CHANGE AT YOUR OWN RISK
// These constants were once customisable but their fucntionality should now be
// considered deprecated.

A little further down, another possible boo-boo.  Before and after, only tabs are used.  But for one line, a few spaces instead of another tab in order to line it up properly.

				// Enable debug on hooks?
				// By default, if a hook throws an exception, the exception is caught silently and the parent
				// method is executed. Turn this on to log those exceptions.
			    'DEBUG_HOOKS' => FALSE,

Now before anyone gets worried, I'm sure that these critical issues won't cause any problems for anyone.  So no one needs to shut down their community until a fix is applied.  😉

Assuming you are on 4.7.11 (or at least 4.7.x), that would be a display name and not a user name.  I'm a bit "out of shape" in regards to my familiarity with the community suite (been inactive), but I'm not seeing any settings for restricting how many accounts can be made from a single IP address.  Either it doesn't exist, or I'm overlooking it.  If I'm overlooking it, please direct me to where it is.

As for the display name, I ask this question (and they are likely doing this same thing)...

Of these four "Hello's," which one is spelled used two lowercase L's and no uppercase i's?

Hello HeIIo HeIlo HelIo

😉