I've been asked to update a client's Joomla! template to have a new header image, but I'd ideally like a way to make the change and display it to a client in a special area, without it compromising their main website until approved.
Is there any way of doing this without checking out their entire website, installing it as a local development branch, checking it into another development server, and then migrating the change after approval?
I use the term "A/B Development" in the way that "A/B Testing" is used -- ultimately forking small changes to different users, except used on a micro scale (unlike normal A/B Testing, where a small variation is pushed to a wide user base, from which some sense of empirical effectiveness can be tested).
Thanks!
In your Joomla backend duplicate the template and make the changes to it. You can then set your customers user account to use the dev-template, or assign it specific menu items that are hidden (so you can just pass a link, no account and login needed) or match appropriate permissions.
Sure it can be done, but it really depends on how your template is coded. Here are the two most common I can think of -
If your header image is in a module simply create a new module with the new image. Then create a hidden menu item and assign the new header to that page.
If your header image is a background image, then you will need to use the page class suffix to make it work. You'll need to make sure that your template adds the page class suffix to the body tag. Create a hidden menu item and give it a unique page class suffix. Then it is simply a matter of adding the CSS to switch the image on the hidden page.
The correct software engineering approach is to automate your build/deployment processes so that it's trivial for you to deploy to multiple environments. Usually ANT scripts are the glue while TeamCity or Hudson are the project-container frameworks used to package your build processes.
This is all part of a concept called continuous integration, which leads you down the path of automated testing and push-button deployments.
Related
I just got some questions, maybe some of you can answer.
The benefit by Nextcloud / Owncloud and so on is more than just uploading taking files with you and so on.
It does version the files, make them downloadable - as well secure behind.
It would be benefitial for me and most everyone who is dealing with the Question:
"How to upload documents, link them in some kind of Database (which main purpose is to operate with information) and versioning, saving, editing and so on does not need to be implemented by me / others, because it is handled by Nextcloud (in my case prefered)?"
Is there any script outside, or maybe some kind of plugin to have that benefit?
In my vision I would need:
One "Drag and Drop" Area for Documents / Pictures etc.
This should have a hidden field, which is filled with a id, with which the system can identify the file.
a onetime Link (with retention of that link by one day or so) what is generated by php (could also be a script) and generates a share Link for given id.
(not needed since now, but nice to have:) some script as in 2, where versions of some given File should be viewed.
Some solution could be:
something similar to an "iframe" for a shared link with public upload.
But Im not very happy of using IFrames... Something better would be nice.
Drag & Drop is available in the Web UI. For additional meta data, use a hook mechanism on postCreate (\OCP\Files\Node $node) within a custom app/module you'd need to deploy. For hooks, see https://docs.nextcloud.com/server/12/developer_manual/app/hooks.html.
About meta data: you don't need to store them in a database necessarily, you can also use custom WebDav properties. I wrote a blog post about it recently: https://medium.com/#mathiasconradt/how-to-assign-custom-meta-data-to-your-documents-on-nextcloud-23356cf3f926
Links with a time limit to be valid can be generated manually via Web UI. If you need it automated on upload, use the same approach as in (1): hook mechanism that listens to file creations, as part of a custom app.
at the moment, you can only restore old versions. I think you cannot diff/view them. Would require a custom app.
General info on how to write your own module / app: https://docs.nextcloud.com/server/12/developer_manual/app/index.html
I have a multilingual project,
the project is fully compatible with HE/EN languages.
In one case it's going to be uploaded as a subfolder in a big israeli project,
in another it's going to be used as a full site on it's own .com domain in english.
I currently have an SVN setup for the israeli project,
I haven't yet created an SVN for the .com, is this the right way to go, keeping 2 depo's for this ? I will then have to make sure that the code written on the israeli project is always copied manually to the .com folder,
Can this be managed more efficiently ?
Yes, this can definitely be managed more efficiently. This statement right here is the main problem:
I will then have to make sure that the code written on the israeli project is always copied manually to the .com folder.
That process is not only inefficient, it's highly error-prone. And it absolutely doesn't scale at all. Basically you're doubling your development/testing/deployment/etc. efforts. If you ever need to deploy another instance of the application, you'll have tripled efforts. And so on.
What you'll want to do is isolate the components that are different between the instances of the application. Is it just the language content? Is it the whole UI? If it's the whole UI then you'll want that UI to be as thin and light-weight as possible. (Well, you want that anyway.) Then all you'd have to double is the UI work. The rest of the logic (business logic, data access, services, etc.) can be constant across all instances of the application.
If it's just text content, then maybe you can re-factor that text to be pulled from the database. Every label, every article, every menu item, etc. There are CMS systems which do this pretty well, though I have no specific recommendations. But the overall idea is to have the UI be an empty wrapper populated by data specific to that application instance. Then each instance would control its "language" (its content in general) by simply managing that data.
You definitely don't want multiple code repositories for this. After all, if you have two repositories of code, which one is the correct one? If a change is made in one repository but not the other, which one is right? Your code should have a single "source of truth." Multiple sources of truth means no truth.
Let's say we created a small widget or web app. or just a plugin - and we want to distribute it to the public. (JS, jQuery...)
...and we have no server- or we are afraid it will close one day.
...and we'd like to provide that script like an url-to-script to be included into a script tag.Like we do with the jQ library -- Is there any provider that allows us to store codes and generates a livetime url to it?? That we can mantain, change or fix it anytime without the need to inform all users?
Have Google something like that?
Or am I dreaming?
You can upload on github. It's free for open-source projects, and you can even link directly to the repo's master branch; example:
https://github.com/douglascrockford/JSON-js/raw/master/json_parse.js
(There are good reasons not to do that as a general rule — the master branch could get a breaking change committed to it, for example — but it's there if you need it.)
Another day playing around with joomla, and another shortcoming to fix :)
This time it comes in the form of the administration(backend) menu.
To add items/subitems to this menu, people have to write the menu items in an xml file accompanying their components/extension/plugin/whatever.
When the extension is installed, joomla "generates" the menu items and "stores" them in the DB.
Effectively, the real/tangible menu is rendered by reading the DB.
This has several implications:
The menu is not scriptable
The menu is not dynamic; changing the XML file after installation, won't update the menu
Removal of items is not scriptable; joomla takes care of removing any items when you uninstall the extension.
I've got this system which relies on the ability to modify menu items on the fly, but through code.
Simply put, I need to have functionality where I can create a volatile menu item (ie, it gets removed at the end of session).
To do so, I've got a couple of prospective hacks:
Override the joomla global database instance so that I can make it return fake menu items. This is possible since the database object is stored in a public property of JFactory class: JFactory::$database=new MyFakeJDatabase(JFactory::$database);
Intercept the menu code (html) before being output and mess it up according to my needs. This is not template-friendly in that the end result would be injecting html, which might not be what the template was designed for.
Create menu items through javascript. This suffers issues with the template AND the javascript that toggles submenus.
Create menu items in the DB whenever I need them and somehow "tag" my items so that I remove them the next time (or end of session). This sounds like it would work like a charm. Since I can buffer menu items, I could possibly create my menu items in one whole SQL statement. Than I could use another SQL to remove the tagged menu items. 2 SQL statements might not be much of a load on the server.
What do you think?
Edit: I've checked joomla/administrator/modules/mod_menu/helper.php to see if I could find a way to inject my stuff, wishing that maybe joomla used a global variable or something, but to no use - the menu items are creating directly by reading the db and rendering as well.
FYI I've searched a while on Google, to no use.
Interesting. I have worked with Joomla for many years, writing all kinds of extensions for various purposes, including integrating external systems. It has been my experience to approach these types of situations by looking at the basic needs of code execution. And I always seem to start off asking: is it UI driven or system-driven?
First, consider if the code will execute according to user-generated system events. There are a whole bunch of 'em and you can even trigger your own. If this is a requirement, then the solution will need to incorporate a plugin, attached to events.
However, for any kind of dynamic UI content, you will need a module. Modules are all about displaying content. These guys are designed for the user experience. So, consider how access to the UI content will be managed. Which users will comprise the "audience" of this content? This is controlled by user groups and access levels. At some point in your code, preferably early, you will have to check the user's rights and then modify your code execution in response. Thankfully, I find that someone has already done a lot of the work for me. How?
Find an extension that performs the things that your code needs to do, or as close as one might match up. The entire CMS is built with extensions running atop the Joomla! Framework and there are thousands of extensions available for download. Once you've found it, clone the thing. Then edit it so that it does what you need it to do, plus what it did before (if that is a requirement). Install your updated clone, unpublish the original and publish yours. Saves a lot of time.
Looking at your requirements, the code only executes as long as there is a session. I would start with with a 'user' type plugin. When the user triggers a login event the plugin can add the dynamic menu records to a session variable as an array of db records. When the user triggers a logout or the session times-out, the records will go away by themselves. Then I would simply clone "mod_menu" and have read in any records that it finds in the users session. I use this session variable technique all the time, especially when implementing analytic data gathering stuff.
Anyway, I don't post often; but I sure hope this helps. I would love to see this type pf functionality myself. Just haven't the time to code it.
Good luck!
chozyn
The "correct" way would be to write a module which overrides the core menu module to achieve the old functionality with the added feature of dynamic menus from whatever source you have. Not particularly a nice way to go, but that is Joomla's way.
Thanks to #ircmaxell to point this method out.
No hack seems satifactory, safe or maintainable enough to achieve this.
I've aborted the project and instead am putting buttons in the main dashboard through JS.
It's highly inconvenient to end users (they still miss sub-items). But what the hell...it's Joomla's fault.
Oh and for the record, I needed to add my own custom "pages" similar to admin components. Guess what? That failed as well, so it's another hack.
Hope that by version 1.7, they[joomla] trash the initial codebase altogether.
Can somebody please tell me what is the basic difference between the module and component in Joomla?
If possible, please tell with some examples, so that it is easily understood.
Modules are usually small pieces of functionality designed to _present information in your site). They can appear a number of times, on a number of pages in various positions.
On the other hand, a component is typically more complex, with extensive functionality and capabilities. A component can only be displayed in the main area of a page, and can usually only be displayed in a single page.
Read this article for more info:
http://www.dart-creations.com/joomla/joomla-tutorials/the-difference-between-modules-and-components.html
Taken from http://forum.joomla.org/viewtopic.php?t=344599#p1485432 by David Hurley.
When I'm working with clients here is how I typically explain the differences.
A plugin will manipulate output already generated by the system. It typically does not run as a stand-alone piece, but takes data from other sources (i.e. the content) and manipulates it before outputting to the user window. A plugin typically does not display directly to a user, but does its work behind the scenes.
A module is typically considered to be an add-on to the site that extends the functionality of another part of the system. It usually has fewer options that are configurable by the end user and most of the time does not handle any storing of information into the database. A module usually occupies a secondary portion of the web page and is not considered the primary focus of a page.
A component is the most extensive add-on. This typically adds completely new, or different, functionality to your site and extends the overall site possibilities. A component handles data manipulation as well as input and storage into the database. A component on most sites occupies the main area of the website layout and is the primary focus of the page.
These are just generalizations and there are exceptions to every rule, but this should give you a good starting point.
As far as I can see, any reason for distinguishing between components and modules is hidden in the technique of the Joomla framework. The fact that the main editorial content of a page is provided by a component, whereas subsidiary information (side frames, headers and footers, etc.) are provided by modules is not a real difference as far as the user is concerned. Page content is page content - full stop!
I think it is misleading to confuse users by stressing this difference. The way modules associate with menu items is probably technically different to the way the components do. Components are associated with a page on a one to one basis and they are run by triggering a menu item. Also modules do not always need to access the database whereas this is an integral part of a component. I expect these technical differences ultimately explain why Joomla has built the distinction in the the user interface. Perhaps avoiding this distinction would be the basis for Joomla version 4 - but I suspect this would mean starting from scratch with a totally new CMS :(
A component always displays its results in the "mainbody" area of your template.
A module displays its results outside of the "mainbody" ... usually along the side, top, or bottom of the mainbody.