For me, I recently discovered that adding[the log the user in workflow action and checking off keep user logged in option] after the [sign the user up workflow action] will keep the user logged in forever after s/he signs up for your website. If you don’t do this, the user’s first session will be logged off automatically after 24 hours.
This is what all the social media apps do. They try to never ask you for your password again so they never log you out.
Here’s one (very, very advanced):
There’s a bug in the plugin editor: The plugin editor has “copy” and “paste” element features. You would think that you could – for example – build an element in a plugin and then use that as a template for building a new element that is similar, but has different features.
However, if you do this, it turns out that your “copied” element is not, in fact, a copy, but a clone. The actions and states of the “copied” element will conflict with the “original” element.
But you can work around this by copying your entire plugin to a new copy of the entire plugin. Now, copy the desired element and paste it there (create a “clone” of the desired element in the copy). Sync to Github.
Now go inspect your elements in that Github repo and you’ll see the source of the bug – the cloned element shares the same unique IDs for actions and states as the original. (These IDs show up as folder names and names in params.json.)
To fix: Download the repo to your local machine and change the IDs in params.json (you’ll see that the original names have 3-character names that must be something like low-resolution unique IDs – they are like AAa, AAb, etc. Just change them to – for example TAa, TAb, etc.). Then change the folder names to match (this isn’t very hard). Check your code in and commit to your master branch in Github.
Now back in the plugin editor for the copied plugin, you’ll see that the github repo is ahead of the plugin’s branch. Resync and you’ll find that your modified plugin element is now a unique entity, and not a clone.
Now you can proceed with development.
It’s stupid that Bubble implemented plugin elements this way. (Why don’t they simply have a master unique ID?) But at least it can be worked around.
I’m the only person in the world who understands the above, BTW, but I hope that – in future – others who trod my path will benefit.
Hey @cdorozco16, this thread is a very good idea!
There’s a not so obvious trick that I discovered here on the forum and I’ve been using it a lot since:
Using booleans with :formatted as text.
Let say I have a group that should display a user comment. And let says that if the comment is empty, it should display “No comment here!”. I would use and expression like:
This message's Comment is not empty :formatted as text
and in the configuration of the :formatted as text panel, I would use for yes:
This message's Comment's value
and for no:
"No comment here!"
This kind of logic can be applied to so many places and can spare building workflows with event listeners to dynamically change values…
A very similar thing must happen when you “copy with workflows” on repeating groups. Deleting the original will cause a bug that removes all associated workflows or data calls the rg, including “do when a condition is true”, customs and page loads.
Doing this also seems to fix the it with apps where you copied with wf.
I really hope not otherwise how are they going to fix it
@julienallard1 I had no idea you could place dynamic data in there 
thanks for sharing!
Great thread idea @cdorozco16
Better Searching
The below was done without plugins
Tl;dr Example App / Editor
What is the secret to the partial match search?
Regex
\b(?=\w{0,20}\b)\w{0,9}(Input A's Value:lowercase)\w*
Repeating group with the following data source:
via Do a Search for: filtered > Advanced : this item's name:lowercase:extract with regex
How do you get the auto dropdown search results?
-Focus group (for dropdown)
-Repeating group (for results)
-Conditional workflows triggering show/hide of the focus group
-A couple of other workarounds to polish the UX
I recently posted in the Tips category about a technique that leverages booleans to allow string literals to be added to a dynamic expression, since not all dynamic expression fields allow concatenating string literals with other dynamic expression components. Rather than reiterate, you can read the original post.
p.s. Shouldn’t this entire thread be in the Tips category, BTW?
Yes, done! 
Taking it one step further.
tl;dr Example App / Editor
Include everything from the last post above and add in:
Users, Photos, and States
DB Performance Note
The example represents a fairly complex search of the database. There are lots lots of simultaneous queries going on and it could be taxing to performance so you’ll want to consider this. My solution to speed things up was to fetch every DB item during page load and store them a ‘list of things’ page states. That may not work if the database is very large. I do know that even with < 100 items in this test app db, the real-time performance before everything loads is very poor (many seconds) unless you preload load your database items. In this case there were 3 db types: list of Users, list of States, & list of Photos
I’d imagine its possible that if you’ve got a mix of predictably small number of db item’s you’ll be searching (there are a predictable amount of 50 us states), you might just load those db items onto the page and get a partial performance boost.
I honestly don’t follow but I would like to learn more bc I use a lot of boolean conditions.
Could you give an example of how the set up for your user comment example would look like if you were not using your bool trick?
In the example here, the yellow square use a boolean to show the content of the input element if not empty or to display a static message saying “No comment here!”
As @sudsy posted (see above), the blue square demonstrates an example of using custom states. In workflows, when you set the value of a custom state, you can’t combine multiple values in the expression builder. But using boolean:formatted as text, you can.
Cool stuff. Am I correct that the filtering is done client-side, meaning that this approach would not improve data load time for large data sets?
(Note: This is a theory that I have not used yet, just kind of a fun idea)
(Note 2: Yes, step 3 would kill load time for larger data sets. If I used this, it would likely only ever be for relatively small datasets.)
Combining 2 data types in a single RG:
Let’s say you want to combine 2 data types in a single RG search result. For this example, we’ll be combining “Coffee Blend” & “Soda” data types and we’ll be sorting the results by caffeine content.
Step 1. Create a repeating group of Coffee Blends and sort by caffeine content (descending). We’ll call it “repeatinggroup coffee”. This will eventually be the combined repeating group with both data types.
Step 2. In a hidden element (I usually put things like this in a popup and just refer to them as needed) Create a repeating group of Sodas. We’ll call it “repeatinggroup hidden soda”.
Step 3. WITHIN the first cell of “repeatinggroup coffee”, underneath the content you’ve created to describe the Coffee, create a repeating group with the type “Soda”. Set the data source of this RG to the following:
The result should be a combined list of coffee and soda, sorted by their caffeine content in descending order.
Anyway, happy Bubbling!
Yup, client side.
The full list should be loaded into a hidden list of things and the RG in the focus group should have it as its source to filter.
Just curious why a UI element would be used when it’s never actually going to be shown. Couldn’t a custom state be used for this?
Yep, you’re 100% correct, @sudsy. There are 2 reasons that folks don’t use a custom state:
… but it’s silly to use a repeating group simply to hold a reference to some list when you don’t intend to visualize anything.
Another alternative to using a custom state is to use my awesome List Shifter plugin, which one can think of as a repeating group with no visible component or a custom state will a bunch of extra utility functions on it. Since it has a field for the source list, you don’t have to execute a workflow action to populate its list. It just happens automagically on page load, just like a “hidden” repeating group. (Also, iteration.)
Aside: It kind of doesn’t matter as @nnich19’s example will not actually work. Because:
repeatinggroup coffee’s list of Coffee Blends: Item number [current cell’s index + 1]'s Caffeine content
… is not an expression that you can build (because no parens).
That sounds pretty cool and useful. I’ll have to check it out. 
Or 3, they read from one of the hardcore bubblers that an RG is slightly faster than a custom state 
I would be very happy if that’s not the case as I much prefer custom states. They feel more organized than an invisible element.
The way I understand it is that a hidden repeating group doesn’t actually populate until another element calls on its data. Does the List Shifter actually populate on page load or does it render the same as the hidden RG?
And 4., the RG list is automatically refreshed when you do changes on the DB.
For example, if you have a list of 4 items in a RG and in a custom state from your DB and you delete one item:
the RG will show :count 3
the custom state will show :count 4 with an empty row
So the question is more like why would you use a custom state instead of a RG and make your life more complicated than it should be.
Combine small data types into a new data type.
Why did I need it?
I have an application where my users store their data. However, they may cancel their subscription one day and will want to export their data.
Problem: These data types were divided into small pieces for performance, of course the user thinks of them as a single data type.
In order for this data to mean something to the user, I tried to combine the data into a new data type using Schedule API Workflow on a List. As the list grew, things became harder and I needed to increase the capacity of 2 units for 400 lines.
Instead, after creating (A or B …) data, schedule the API workflow to create one (E) data.
Adding related data individually results, in faster than converting data at once and protects against cost increases
