I am running a server that hosts several disjunct instances of MediaWiki for several customers. There are a few set of CSS adjustments, which I would like to apply server-wide and "group-wide".
I already checked out WikiPedia's stacks of CSS classes, but they are all predefined and would most probably be overwritten on updates.
It would be perfect, if there were some kind of css.d folder, where I could store links to CSS files, but to the best of my knowledge there is not such a thing.
How should I realize sharing a CSS file among several instances?
Within a wiki family, install the GlobalCssJs extension and edit the MediaWiki:Global.js/MediaWiki:Global.css pages on the central wiki (manual), as you would do to customise a wiki's CSS.
Alternatively, write your own extension to make all your custom changes in a single place (the code repository) and then deploy them to all wikis with the usual methods you use to update code.
Related
I'm thinking about changing the processCSS gulp task that Aurelia CLI creates to create physical css files, instead of including it directly in the app-bundle.
Are there any major drawbacks within the Aurelia framework to doing this?
I'm more comfortable with separate css files after preprocessing, but I don't want to do it if I'd be missing out on some performance benefits, or create other troubles down the road.
I don't think there's any major drawback that can't be reasonably overcome. However, I would try to evaluate the benefit of doing it your way, instead of bundling it together.
I'll list a couple of points I can think of, in no particular order.
It can be challenging to get the modules and paths set up correctly if you are requiring CSS from standalone CSS modules. If you are using plain CSS files, then you will need to included and maintain the Link tags in your host HTML page. All this is easier if the CSS is bundled directly into the app bundle. Especially when adding more CSS due to 3rd party libraries etc.
if you are using the organizational pattern where you create css-per-component instead of having one monolithic CSS file, then there are potential performance impacts to making http requests for each individual css file, although the impact is probably more thoeretical than practical.
when deploying, it is really nice to just deploy a minimum number of files.
when all css is bundled, you can add comments at top of each CSS source file to help identify the source file when looking at the CSS in the browser inspector.
One last thing, it may be worth your time to experiment loading the CSS in different ways, including as individual files and see which way works best for your environment.
I'm trying to figure out a way to make Phabricator manage several unrelated products. I installed Phabricator, imported a few source repositories and customized the side menu by adding all the default Phabricator applications (just to get an idea of what Phabricator offers "out of the box").
At first, I liked what I saw, but after spending a bit of time exploring, it started to appear Phabractor is just a collection of various SCM tools that are not linked together. I'm really looking for a set of top level "Products" and under each I can create various related Wiki Pages, Tasks/Bugs, [sub]Projects, Uploaded Files, Legalpad entries, etc.
What I am seeing, for example, is a general Wiki Engine (Phriction) that is no way linked to a Project or a top-most Product. Also, I can create a Legalpad document, but again cannot assign it to a project or product. Same with Files I upload. Even my imported source code repositories are just floating out there without any link to a Project or Product.
Am I missing something? Is anyone using a single instance of Phabricator to manage multiple unrelated products with potentially different groups of end users?
One potential work-around is I could setup a custom Dashboard for each of my products and link in the associated projects, tasks and even links to related wiki pages, but seems like a lot of work for each product and it still seems there is no way to categorize Uploaded Files and Leagalpad.
#Flagrama answers is most of the reality. If you want simple hard separation like you could find in other tools like Redmine, Phabricator is not conceived this way.
Now there is something that could make thing a little more natural: Phabricator Spaces.
It allows to split things pretty neatly. You can see the doc here:
https://secure.phabricator.com/book/phabricator/article/spaces/
In Phabricator you can create a Project. You can set it up so that anybody can join it, or so only administrators can add users. You can also make projects only visible/joinable to members of other projects.
"Visible to Members of Project..." is the basis of managing unrelated projects in Phabricator. Every repository you create, page you add to the Wiki, file you upload, or LegalPad document you create can be set to only be visible to members of a certain project.
Unfortunately I'm pretty sure this is the limit of Projects in Phabricator at present so it may still not meet your needs.
Phabricator is very flexible and includes several different ways to organize your work and your workflows.
Spaces
Another answer already suggested that you could try Spaces, which is a sort of global grouping and that can be used to isolate everything within one space and keep it almost entirely separate from everything that's in another space.
Projects
Phabricator also has a concept of "Project Tags" which you can use to organize tasks, repositories, blog posts and various other "Objects" within the various Phabricator applications. Most objects support one or more tags and the tags are defined by Projects which you create. Tags can be used as free-form labels or you can create a hierarchy of projects and sub-projects.
I'll go into a bit more detail about using Phabricator's Projects feature since that is how I've used Phabricator so that is what I'm familiar with.
Organizing your work with with Projects and Tags
Create a top level project for your tool, product, team or whatever makes sense in your situation.
Tag the repositories, wikis pages, blog posts, tasks, etc which belong to the project created in 1. using the project's #hashtag.
Customize the menus on your project to link to related repositories, wikis, documentation, etc. The project menus are quite flexible, as are other "profile" menus such as dashboards and user favorites menus.
Use the project's workboard to manage tasks related to the project.
Create subprojects, milestones, etc as needed.
6, Repeat 1-5 for each project you work on.
Here's a situation I run into a lot with CSS architecture using BEM/SMACSS. I'd like to see how other developers handle it.
You have a library of CSS modules that you use across multiple sites. Modules like .btn-group, .nav-tabs, etc.
Then you encounter a module that's styled in a very site-specific way -- it's too unique to be able to use one of your library modules.
So you have the code for that "site module" in a Sass/Less file and you save it with the other style code for that site, like the layout styles. It's not saved with your "library modules."
My question is: do you do anything to distinguish the "site module" from your "library modules"?
I usually follow YAGNI principle in CSS which helps making decisions in these sort of circumstances. Following always implement things when you actually need them, never when you just foresee that you need them approach a new module starts its life as a site module. Whenever I need to use that module in more than one site then that is the moment I consider turning it into a library module.
This issue is solved with the help of Levels of Definition.
The main idea is that you can split blocks (even parts of the same blocks) into different layers which you combine on a project. E.g. you can have library level (or a few of libraries) and a project level or it could be different levels according to environment: common parts for all the platforms and different ones for desktop and tablets and so on.
See http://bem.info/method/filesystem/ for more details.
I'm working on a premium theme for WordPress, it's my first. My question is how modular should/can I get my code before it gets to be a problem for the server or other developers who buy my theme?
For example I have 3 custom post types with taxonomies and custom column headings. Should they all be in one php file or can I break them up so that each post type is in its own file?
I'm thinking that for future projects more modular is the way to go so I can just drag and drop the pieces that I need for that project. I don't want to make my theme any slower though so I could use a little advise on how granular to make my files.
I've bought themes in the past that have both extremes but want to set myself up properly from the start.
Thanks.
This is an opinion request this one because either approach works and based on this information plus the fact you seem keen on individual files. I would encourage just that.
Modular approach works with themes if you plan to provide the same functionality per theme as you won't need to edit functions per theme. I would go with individual files and just put them in a folder. If one of those files has a bug you'll be quick on applying the changes to all the themes you create.
If you put all the functions in one file and each theme gets its own versions of those files due to requests etc. Then you create a little more work in that you copy and paste code. Not a lot of work but then that demands on just how much that single file changes over the years or even within some months.
There is nothing wrong with many folders and files. It won't have an effect on loading. It would take hundreds of include() or require() before it becomes an issue.
Several popular CMS's such as Drupal, Wordpress, etc. have an index.php file that is pretty much empty except for a include/require statement that includes some other PHP file (as in one file) containing all of the bootstrap code for the CMS. What is the rationale for this? Why not just move all of the bootstrapping code into index.php if it is doing nothing other than including the bootstrapping code anyway?
I'm trying to build a CMS as an example project to improve my PHP skills, and I'd like to understand what design considerations led them to do it this way. I understand the benefit of breaking up applications into multiple files, but I've never heard of making a file that does nothing but include another one. Obviously there is some benefit, since several major CMS projects designed it this way, but I just can't figure out what it is.
Can someone explain to me the reasoning for this?
In Drupal's case, there are other files that do a similar bootstrap. These typically aren't normal pages, but do serve important purposes. Off the top of my head cron.php, update.php, and install.php do this. I use the bootstrap process at the beginning of custom import scripts, as well as scripts that get called by cron that I don't want to use a hook_cron for.
I can think of two reasons:
When using a product like Wordpress, you sometimes end up adding user hacks to the front controller - say, setting custom constants, specific redirects, or an additional layer of access control, or whatever. An empty index file allows you to add that kind of stuff without disturbing the product's original code.
Having everything in a separate bootstrap creates the possibility of moving all code (including the bootstrap) to a location outside the web root, and include it from there.
Aesthetics mostly. You can have a clean and neat directory structure (outside of webroot), in which bootstrapping files are separated from index.php file. There are probably several of them (vs. one index.php file) and they are doing different things (db init, authorisation).
I also found one or two CMS which start in debug declaration (in order to switch display errors and warnings before including any files, so you can have your errors printed before php includes a file with syntax error, but that's not really a good practice).
I would say this is good design because you can easily change the path to the bootstrap, which makes it very easy to change location of the CMS, if ever necessary.
Another good reason is you could also be running a dev CMS while developing, and roll out new versions with one path change in the index.php.