I want to know if a extension (for example: joomfish) is really used or not used at all before i disable it / uninstall it.
Is there a way to check ?
First, in Joomla plugin has a specific meaning, so what you want to know is whether a component, module or plugin is used.
This is a common problem when you inherit sites. A lot of times users install tons of extensions and never use or uninstall them.
The simplest first step with modules and plugins is to see if they are published or not. Also you can look at modules and see if they are assigned to any positions or menu items.
In terms of extensions, if they are a kind of extension that would be used to create content and you look at the manager you can see if any content was ever created. If not it is probably safe to uninstall. IF there is content then you will want to figure out whether you need o preserve it.
The problem with Mike's answer is .. how do you know if you have tried every possible combination of things or possible events with enough certainty to say for sure that something is not running ever. For example you may have a component that you never use as a menu item but then some module is running a query against its data.
Well you cannot know that. To be absolutely shure you could write a system plugin which gets triggered on plugin calls and logs the triggering plugin names.
Related
In my extension (a plugin) I want some SQL scripts to run every once in a while (some database cleanup operations); once a day or once a week would probably be enough. Doesn't need to be exactly in that interval, it would be well enough to be triggered if someone accesses the site.
In an ideal world those would probably be run by a cron script, but not everybody using my extension will have access to the crontab on their server, so the solution needs to work without cronjobs.
Searching for "joomla cronjob" and combinations of it I haven't yet found anything already existing in the Joomla framework (just additional extensions, like JPrc Cronjobs; but it needs to be either existing in the framework already or included into my extension).
Thinking about implementing it myself (since my plugin already runs on every site call anyway), the immediate solution coming to mind is storing a timestamp whenever doing the operation, and then for the next operation run, checking whether the appropriate interval has already passed.
However, where would I store the timestamp? A separate table seems complete overkill (although it would probably be the cleanest solution). Is there maybe some simple key-value store for Joomla extensions? I didn't see such a thing yet either.
So, my question boils down to:
Is there a functionality within Joomla framework (working on Joomla >= 2.5) which triggers some code every once in an interval?
Alternatively, is there a place to quickly and simply store a single key-value pair?
Since your code runs on every page call, your second solution would be much simpler to implement. You can utilize the built-in extension parameters to store an extension-specific value.
First, take a look here:
https://stackoverflow.com/a/13221472/1867759
This solution would work perfectly for you. The only difference would be that, since you're already within your plugin, you can access the parameters via $this->params rather than calling them from JComponentHelper.
Hope this helps!
I need help setting up my SCSS file watcher in PhpStorm. I'm on Ubuntu, I have PhpStorm 6, I have RVM with Ruby 1.9.3p194 and Sass 3.2.5. I've set my File Watcher options in, Settings >> File Watcher as follows:
Once I had done that, I changed something in my .SCSS file but I got this error.
...-1.9.3-p194/bin/sass --no-cache --update style_update.scss:style_update.css
/usr/bin/env: ruby: No such file or directory
(I added three dots at the begin of the first line to make the line shorter) So what might be the problem?
The problem is that IDE is not able to find ruby in the PATH. Note that it may be different in terminal and in applications that you start from Ubuntu launchpad.
Use the Environment variables option in the file watcher configuration to specify custom PATH value with a directory containing the required executables.
A quote from an answer/comment before:
"[...] ... just do what is written, add PATH variable ... [...]"
... That's exactly a common misunderstanding between helping people (who are mostly not teachers), who do the tasks on a daily basis, and asking people on the other hand, who can imagine 3 different things behind standartized answers and their words. Stackoverflow should extend on this, not repeat manuals or documentations.
In PHPstorm for example, you have 2 empty fields after hitting the plus on the right corner of the Enviroment variable settings window. The left field has the header "Variable", the right field the header "Value". So, if somebody is not familiar with PATH and ENVIROMENT variables of desktop or server systems, this person will be slidely confused about what has to be placed in the first field. Is it "ruby"? Is it "PATH"? Wouldn't it override the whole PATH variable of the system? Is it a custom given NAME I can choose and how does the system knows about it? No explanation can be found.
If you don't know the logic behind, you cannot assume the right steps from this standart formulated advice. While I am very excited about the feature set of PHPstorm I find the documentation slidely too standartized and unexplainable. Thats why many entries have bad votes from readers below. Like if somebody would ask: "how do I bake bred?" and the answerer says: "First you have to prepare flour and create dough, then you can bake bred." So what do the asker has learned from this answer? Exactly. Nothing what he didn't knew already before. Ok, maybe the question was not clear enough, but this is also a common case: how to ask correctly if you don't know what you actually ask for? From where can the person know, that there is a need to understand how to set PATH variables? I think this is what differs between makers and teachers. Teachers learn to communicate that gap. Documentation often lacks of better teachers writing it. People who work in the support team should be better in thinking like teachers.
To become more constructive: The documentation of PHPstorm says in its example: "choose PATH_TO_LIB as NAME and the path to the library for the VALUE field." Again: from where does this PATH_TO_LIB comes? Is it an own given Name, or a prepared empty VARIABE name PHPstorm watches? If something wents wrong and you start to look for issues which may cause this and start to worry about wrong settings you are lost on this questions even as an experienced PHP developer.
I generally prefer using tools like guard and RVM based ruby installations ATM over build in watch file solutions like these from PHPstorm, which mostly look for a system wide ruby and such first. But with rvm we have project based paths to ruby and such. RVM prevents breaking the compiling-chain of long term theme or module developments based on certain gem versions. Watch here http://www.youtube.com/watch?v=CmTuvzbPduI where Sebastian Siemssen (well known Drupal developer) explains why this is a good concept. But to nicely implement this with PHPstorm features, you need a better low level entry to path editing in PHPstorm.
Sadly this involves pressing save again, since this needs the save file event to be triggered. I would love to see a better implementation, flexibility and better explanation of how to go with the PHPstorm in-build watchers to have a refresh on edit at hand.
I was wondering if it was possible to intercept or disable different Visual Studio commands or features from an extension?
For instance, could you stop a user from accessing the File -> Open command? I'm trying to work on an extension that will help enforce some coding standards and as part of that I'd like to disable or intercept a few different things when users try to do them. For instance, maybe disabling the ability to edit project properties or something similar to stop users from checking in their local changes and breaking the build or messing up other team members.
Do hooks exist for this in the Extension API or are we stuck with the old Word document asking people to play nice?
You can, but I do want to echo Greg's comment before I give details: you are better off spending your time making a really awesome tool that developers can run to catch "bad problems" than playing whack-a-mole to disable commands. Disabling commands could be dangerous because there are often multiple commands that might do the same "bad" thing. Also, disabling might cause other parts of VS to destabilize. Using your example of project properties, write a tool that runs across your codebase and looks for project files that are "bad", and spits out a build warning. Have this run every time your developers hit build. That way they still get the near-real-time feedback, without having to make sure they have extensions installed. (plus, you can check that tool into your codebase to ensure everybody is synced)
That said, implementing a IVsRegisterPriorityCommandTarget might be the right option here. The performance ramifications can be significant, so you need to make sure your implementation is fast or else you'll slow down VS. If you return E_NOTSUPPORTED from the handlers, that will result in normal routing. Returning S_OK but not forwarding would block routing from happening.
I'm creating a module that requires a few things to be done (once only) when the module is installed. There may be a number of things that need to be done, but the most basic thing that I need to do is make an API call to a server to let the external server know that the module was installed, and to get a few updated configuration items.
I read this this question on stackoverflow however in my situation I truly am interested in executing code that has nothing to do with the database, fixtures, updating tables, etc. Also, just to be clear this module has no affect (effect?) on the front end. FYI, I've also read this spectacular article by Alan Storm, but this really only drives home the point in my mind that the install/upgrade scripts are not for executing random PHP.
In my mind, I have several possible ways to accomplish this:
I do what I fear is not a best practice and add some PHP to my setup/install script to execute this php
I create some sort of cronjob that will execute the task I need once only (not sure how this would work, but it seems like it might be a "creative" solution - of course if cron is not setup properly then this will fail, which is not good
I create a core_config_data flag ('mynamespace/mymodule/initialized') that I set once my script has run, and I check on every area of the adminhtml that my module touches (CMS/Pages and my own custom adminhtml controller). This seems like a good solution except for all of the extra overhead every time CMS/Pages is hit or my controller is hit, checking this core_config_data setting. The GOOD thing about this solution would be that if something were to fail with my API call, I can set this flag to false and it will run again, display the appropriate message, and continue to run until it succeeds (or have additional logic that will stop the initialization code after XX number of attempts)
Are any of these options the "best" way, and is there any sort of precedent for this somewhere, such as a respected extension or from Magento themselves?
Thanks in advance for your time!
You raise an interesting question.
At the moment, I am not aware of a means to go about executing any arbitrary PHP on module installation, the obvious method (rightly/wrongly) would be to use the installer setup/upgrade script as per 1 of your Q.
2 and 3 seem like a more resource intensive approach, ie. needlessly checking on every page load (cache or not).
There is also the approach of using ./pear to install your module (assuming you packaged it using Magento). I had a very quick look through ./downloader/pearlib/php/pearmage.php but didn't see any lines which execute (vs copying files). I would have imagined this is the best place to execute something on install (other than 1 mentioned above).
But, I've never looked into this, so I'm fairly interested in other possible answers.
Can I create a symlink to the local extension from aonther project folder? I have a common local-server and i need to implement same extension on all local project-installations. I tried to put the symlink, but some times i do not get expected output. I get it only after clearing the cache of that perticular project.
Your scenario is a common one I guess. But as Omar said, linking to the same code base of the extension through several typo3 instances is not a good practice.
But we have the same structure as yours, we realize this through SVN. All of our projects got a SVN repository and common extensions have their own repository. Through svn:externals the extensions are linked into the concrete project. This has the advantage that you can change the extension in the concrete project and after committing all other projects (that do have to update from svn though) contribute from it. I Think this would fit your needs, too.
If I understand your question correctly you have several Typo3 sites on the same server and want to share an extension between them using a symlink. I don't think that is a very great idea because many extensions use tables and every site normally has it's own database so you would have to do a lot of tinkering to get that to work.
Instead you could make all the modifications to the extension files in the typo3conf/ext/extension_name folder and then export the extension to a t3x file (Ext Manager in the Backend). This t3x file can be installed as a extension (Import extension) on all your other sites.
If you extension does not use a database and you are planning to make frequent changes then I guess you should be able to make that work (the symlink). Otherwise I recommend you use the first approach I described.
I have not tried this, but you should be able to install extensions globally in Typo3. What this means is that the given extension is placed inside '(typo3_src/)typo3/ext/' instead of 'typo3conf/ext/', presuming both sites use the same Typo3 Core/Source (and thus typo3_src is a symlink to the location of the core).
You can enable installing global extensions via the Install Tool. Once inside the tool, click on 'All Configuration', then search for allowGlobalInstall. Or put the following line into your localconf.php:
$TYPO3_CONF_VARS['EXT']['allowGlobalInstall'] = '1';
At last, but not least, you need to make sure the 'typo3/ext/' directory is writeable.
Hope this will be to some help. If you have any further questions, let me know :)
As Björn mentioned, I'd sugegst to install them globally. Mind you, updating the source will require to move the extensions accordingly..
As for "expected output": be aware that the code in these folders is cached in various ways (mainly page content and config settings), and hence not always run. This is the reason a change done from "outside" the current installation is likely not to propagate to your output without clearing these caches (as you have observed).
When you actually install an extension via the extension manager, the cache should (if correctly configured) be cleared (interested parties may search for clearCacheOnLoad in class.em_index.php to reveal a clear_cacheCmd('all')). There is a small checkbox, which is normally checked, during the installation process to accomplish this.
Omar's first approach is therefore, as I see it, the more easy way to get "expected output" and less jumbling around with global extensions.