+- UserSpice (https://userspice.com/forums)
+-- Forum: Miscellaneous (https://userspice.com/forums/forumdisplay.php?fid=28)
+--- Forum: Modifications and Hackery (https://userspice.com/forums/forumdisplay.php?fid=29)
+--- Thread: Common Modifications (/showthread.php?tid=271)
Common Modifications - brian - 09-15-2016
Hi everyone, if you have any modifications you have done to UserSpice (any version really), let us know by replying below...something to the effect of "I needed to do X so I modified Y and Z to accomplish it". We want to determine whether there are any common mods people are making, and maybe haven't already brought them up here for discussion.
This will help us understand whether there are some features or "plugin" style developments we need to include in US5 or 4.2.
Common Modifications - plb - 09-19-2016
Can I assume that modifications we've already submitted through the forums but haven't made it into an official release are already on your list?
Common Modifications - mudmin - 09-19-2016
Yeah, for the most part if I've seen them in the forums, they're on the list. If there's something nagging that you want to double check, PLEASE let me know. The bulk of our attention the last few weeks has been on 4.2/5.0 so something could have been missed. In fact, I think a few patches from 4.1.5 and 4.1.4 didn't make it into 4.2 somehow, so I'm double checking those.
Common Modifications - brian - 09-19-2016
I guess my thoughts on this would be to try to establish some of the modifications that might stand out a little more, namely because more than one person may have mentioned a type of mod, or perhaps it is just a really good idea.
@plb: if there is some stuff you believe is really important, then by all means feel free to list them out here again. We don't want to miss anything just because we didn't see it or somehow glossed over it.
Common Modifications - plb - 09-19-2016
Issues listed in descending order of priority - more important, in my view, at the top:
- Changes to DB.php to allow for more than a single condition in WHERE - absolutely necessary, IMHO, to make the query functions usable - http://pastebin.com/0rhnxLB7
- Changes to Redirect.php to allow passing ?foo=bar&a=b type of arguments while still fixing the absolute/relative business. It was driving me crazy (I develop in different directories and US redirects kept getting mixed up) until I made this change - http://pastebin.com/yvSx71U1
- Lots of times I want stuff modifiable in init.php Config::get() rather than having to copy stuff into usersc/ and modify the view or be stuck with a modified includes/ or helpers/ script that I have to keep merging. In general I think it's a good idea, whenever deciding on a default value, to put a little conditional to allow users to override that default via config. I know this isn't specific, but it's something I recommend to your attention. (example is just recently redirecting to a given page after logging in - why have a whole custom_login_script.php when you could just put a value in the Config...)
- Changes in header.php to allow custom CSS for a given page (2 ways provided - one might suffice) - http://pastebin.com/fFWLKvmt
Common Modifications - brian - 09-19-2016
Thanks perfect. I think some of these may be best suited for US5 implementation, since there is definitely more freedom there. Some have already been implemented while others should be up for debate. But again, that is the entire point of this. If no one else chimes in, then we 3 have the debate ourselves
One example I like is the option for changing header.php to allow custom CSS. Things which afford new flexibility are pretty easy to offer as long as they don't impact other functions.
Altering existing functionality (like the redirect) is something we certainly want to consider, but has more potential impact due to the change.
Your third point is something I would like to expand on...do you think it would be helpful starting a new thread to discuss init.php directly? We have already made some changes in US5, for example, moving more stuff to the DB out of the init...also moved some stuff from header.php to the init as well, so that header.php is really just the header info.
Common Modifications - plb - 09-20-2016
I'm not stuck on init.php at all - whatever means of extensible Config is fine by me. But, yes, I'd be interested in talking more about it if you want to start another thread.
Common Modifications - brian - 09-20-2016
Thanks @plb, I think we would like to get a feel on whether others think we are doing the right thing with our init.php. The next time something comes to mind I will be sure to start a new thread where we can discuss the evolution of init.php.
Common Modifications - brian - 09-22-2016
What about forms? What are people doing with the forms? I'm trying to think of how we can handle forms better in US5. Ideally, we could supply forms with the minimal required information on the join form. This would be things like username, first name, last name, email, password, etc. What if we made the join form fields and processing a 2 step process? The first step would input and process the minimal required information above. The second step (if needed) would be 100{3bc1fe685386cc4c3ab89a3f76566d8931e181ad17f08aed9ad73b30bf28114d} customizable by you. You would provide the set of fields for the form, as well as the PHP processing for said form. This would allow us to maintain a "hands off" UserSpice core, while still integrating your customizations into a non-awkward flow.
The problem this is trying to solve is the following: We supply UserSpice with a set number of form inputs and PHP processing. You want to add 1 or more fields to the join form. Right now, you have two options...modify the users/join.php form directly, along with the processing, or our presently preferred approach of copying it to usersc/ folder and modifying that one. The issue is that when we issue an update, that perhaps impacts the join.php page, and it means that we go through our own update, and then on top of that you need to then go through and update your copy of the form in usersc/.
The new approach described in the first paragraph would mean that our updates would only impact the UserSpice provide forms, and your forms remain untouched. When we issue an update, there is no need for you to change anything, it will execute and display your code as you defined it.
So what say the masses?
Common Modifications - plb - 09-22-2016
If I'm understanding correctly, it sounds like it complicates the end-user's experience for admin easing...
Can we do a mid-form processing like this:
if (file_exists(usersc/custom_join.php))
include_once(usersc/custom_join.php);
And then do a little "magic" in the actual saving section by examining the GET/POST data and comparing it to the list of columns in the users table and automatically updating any that match?
I don't recall off the top of my head how y'all have structured your validate() calls, so I don't know if that's something that can be extended just by adding to an array or not...