I'm currently adjusting a child theme of TwentyTwentyOne with some minor changes. Originally my plan was to copy template files, after some lookup in the code I realiced there might be a more clever way.
Apprently they have made a lot of functions for parts (eg. twenty_twenty_one_entry_meta_footer() for a lot of parts and actually check if they dont exist before (https://github.com/WordPress/twentytwentyone/blob/ba9f20cad89163761185c0467b346ba42541ae22/inc/template-tags.php#L57)
if ( ! function_exists( 'twenty_twenty_one_entry_meta_footer' ) ) {
function twenty_twenty_one_entry_meta_footer() {
As I have actually only smaller minor changes I wonder if setting those functions might be "best practice" in that context? Where would I actually set those? in the functions.php?
Pluggable Functions was the thin I was searching for: https://codex.wordpress.org/Pluggable_Functions
And goes to functions.php
Related
This is my first post on stack overflow so forgive me if I have made any mistakes around etiquette.
I have recently started working in REDCap and have an intermediate (or less) understanding of work with HTML/CSS. This, in hand with REDCap's lack of resources and counterintuitive design, has made things a bit difficult.
I am currently working to modify the color of alternating rows on a matrix. While other fields offer the option to edit source code, this is not the case with matrices. I have gone to work in the CSV to see if I can make edits to no avail.
My questions are:
Can these edits even be done?
Would these edits be made in the CSV, or elsewhere?
Are there any good general resources for learning about aesthetic design for REDCap surveys?
Thanks for the replies in advance, really appreciate it.
As to your last question, you would be best off speaking to your local administrators and they can put you in touch with other admins via the REDCap Consortium Community who have done a lot of custom work with modifying the survey design and aesthetics.
You will also need their assistance with my suggestions below, for your main question, since you will need some external modules to make these changes, and they can only be installed on your instance by an admin.
So, get the CSS Injector External Module and you can override the standard survey CSS with your own rules. This may be sufficient to do what you need, but if not – say, if the DOM doesn't contain sufficient classes or ids to select in your custom CSS – then you might want to explore the JavaScript Injector External Module, which you might then use to modify the DOM to include classes that you can then style with your custom CSS.
When building applications, especially when using static linking and having a lot of dependences, I often feel that most of this 50-megabyte executable is just unused bloat, especially if consider only the mode I want.
Is there something that lets you run the program in various scenarious, collect data and build the program again (or tinker already compiled code) to remove the unvisited code (replacing things with abort)? If yes, how is it correctly called and where is it implemented?
I'm perfectly willing to use techniques, rather than tools.
What I've done for your problem is get a map file and just look through it.
There may well be a lot of methods for classes you doubt you need. Find out what references put them in there. Chances are it's just because somewhere something fancy was coded, like a bells-and-whistles container class, when something simple would do. Or a whole math library when all you needed was max.
After fixing that, the map file is smaller, and something else is the biggest thing in it, so you can do it all again.
And again...
This can cut out gobs of bloated binary.
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
I currently have lots of documentation to write in markdown and, therefore, I'd like my favorite editor to properly syntax-highlight it.
Problem is: the default color scheme of SublimeText (in my case, Monokai) doesn't seem to make a good use of colors with markdown. See by yourself.
That being, while searching for a solution, I found a comment on github mentioning other color schemes working way better for markdown: Cobalt, Dawn and Sunburst.
The thing is I'm pretty used to Monokai (never switched to another color scheme so far) and I'd like to avoid switching everytime I have to work with markdown.
Why does syntax highlight vary that much while I'm only using non-exotic themes ?
More important: what can I do ?
It's slightly annoying, but you can customize the existing color scheme. You simply need to determine the scopes for certain blocks of code, then create a color "binding" for that. I'd recommend copying the contents of the Monokai color scheme out and saving it in Packages/User. That way, you aren't messing up the built in one if you accidentally mess things up beyond repair. This also makes it easy to move the color scheme between machines (if that applies to you).
To determine scope, I'd recommend using ScopeHunter. There is built in functionality also, but I like ScopeHunter better (but that's a personal preference). To find the default key bindings, search for the command "show_scope_name`. You can look at the entries already there for an example of how to set up colors, though if you need some additional clarification, please comment as such. Oh and if you would rather work in JSON instead of XML, you might also want to take a look at PlistJsonConverter
As an alternative, you can try to find someone who has already made the appropriate modifications to the color scheme file.
As part of my job I maintain/develop an internal web application. It has relatively few users and just isn't that big. I've got a global CSS file that contains some re-used styles, but 90% of my page-specific styles really really ARE page-specific; they are things like pseudo-column widths (a lot of my output is just non-tabular enough to make tables a poor choice). I have taken to just throwing a <style> block at the top of these pages.
I know this is frowned upon, but every time I read about the reasons for separate CSS files the only one that really stands out is caching. In this case that doesn't matter; it is WAY down on the list of things I would do if I needed to speed up the application. Are there any other reasons, or can I stop feeling guilty?
every time I read about the reasons for separate CSS files the only one that really stands out is caching
Really?
Every time I read about their usage, the fact that you can change something in a CSS file and all pages that include it will have the change is the most important reason to use them.
Having your CSS centralized is a good thing even if your specific pages have different specific rules. It helps you unify the basic CSS structure across the site and when looking for how a specific effect was achieved it will be easy to locate.
These are all worthy reasons to use CSS files, well above any caching/performance reasons.
I face a similar problem, in that most of my styles are very much page-specific. However, my site is far from small, so I had to find a solution.
What I ended up doing was creating a folder css/pages, and naming each CSS file the same as the page that uses it. Then, my PHP "template" can just check if(file_exists("css/pages/".basename($_SERVER['PHP_SELF']))) and add the relevant <link/> tag, resulting in minimal effort on my part.
Just because your site is small is not a valid reason to disregard efficiency, although I have to say I'm a bit of an efficiency nerd so I'll probably be more pedantic over that :p
Ultimately, there's nothing "wrong" with just putting page-specific CSS directly in the page, just make sure that anything that is used on more than one page is in a file so you don't have to repeat yourself.
In my opinion if your app only contain a few web pages(3-5 pages) then you can go ahead define it at the top of the web pages. If your app is going to grow into more that 3-5 web pages then global CSS will help with maintainability and scalability.
Makes for cleaner mark-up, quicker load. Really applies to template and dynamic development. Don't be afraid to use it. It's not like you're going over to the dark side.