I have created a custom plugin(version 1.0) which is already installed in the site.
Now, If i have developed its next version i.e. 1.1.
So, How can I display notification like 'There is a new version of custom-plugin available. View version 1.1 details or update now.', at plugin page in wordpress admin panel.
Would anyone please help me on this?
Thanks in advance !
First of all you have to upload your plugin to the https://wordpress.org/plugins/ using (SVN), You can read about
Subversion.
When you're ready to release a new version of the Plugin:
Make sure everything is committed and the new version actually works.
Pay attention to all WordPress versions your Plugin supports and try to test it with all of them. Don't just test the new features; also make sure you didn't accidentally break some older functionality of the Plugin.
Change the version number in the header comment of the main PHP file to the new version number (in the trunk folder).
Change the version number in the 'Stable tag' field of the readme.txt file (in the trunk folder).
Add a new sub-section in the 'changelog' section of the readme.txt file, briefly describing what changed compared to the last release. This will be listed on the 'Changelog' tab of the Plugin page.
Commit these changes.
Create a new SVN tag as a copy of trunk, following This Guide
Give the system a couple of minutes to work, and then check the wordpress.org Plugin page and a WordPress installation with your Plugin to see if everything updated correctly and the WordPress installation shows an update for your Plugin (the update checks might be cached, so this could take some time -- try visiting the 'available updates' page in your WordPress installation).
The other answer is only correct if you are a major shop. You do not have to use the wordpress repos for your plugins, in fact, if you're not a major shop, DON'T as it pollutes the ecosystem with unmaintained plugins as solos move on.
I use this to ensure that my plugin dependencies are met or show a warning using the update notice.
if ( !defined('MY_MAIN_PLUGIN_IS_ACTIVE') ) {
$file = basename( __FILE__ );
$folder = basename( dirname( __FILE__ ) );
$hook = "in_plugin_update_message-$folder/$file";
add_action( $hook,
function ( $plugin_data, $r ){
echo 'Must activate Main Plugin to use this plugin';
},
10,
2
);
return;
};
Related
I have developed a local plugin and before installation i want to check if a certain plugin i.e. mod_attendance exists in the moodle, if it exists i want to continue with the normal installation else if the mod_attendance doesn't exist i want to return a error message and exit installation. My local plugin works on top of the mod_attendace plugin so i want to check if this plugin exists or not.
I don't know which files to add or edit in my local plugin to add validations before installation.
Your help is appreciated.
In your plugin's version.php, just declare that mod_attendance is a dependency for your plugin, then Moodle will take care of preventing it being installed without it.
$plugin->dependencies = ['mod_attendance' => ANY_VERSION];
See https://docs.moodle.org/dev/version.php for more details.
Back then, I was able to download older subversions of TYPO3 CMS on SourceForge which saved me a lot of time and anger.
Now I am facing a problem and I think it is a bug in the current used version. I would like to test it with an other instance, but as it seems it is not being stored anywhere. I will use an vulnerable version for now, but that is not what I actually want.
Maybe I've overseen a link or something. Do you know where I could find a list of all downloadable TYPO3 Versions? I know I can google it, but I don't want to use 3rd party sources ether...
I'd say that TYPO3 on SourceForge should still be updated...
All versions can be downloaded from get.typo3.org directly. Example for a very old 4.5:
wget --content-disposition https://get.typo3.org/4.5.38
You can use https://get.typo3.org/ for this. Simply append the version number to the URL to download the desired version, e.g. https://get.typo3.org/8.7.15 to download version 8.7.15 of TYPO3 (8.7.16 is the latest ATM.)
If you use Composer you can enforce a downgrade with something like this:
composer require typo3/cms 8.7.15
Or:
composer require typo3/cms-core:8.7.15 typo3/cms-backend:8.7.15 ...
Notice that this replaces the version constraint in your Composer manifest with a fixed version which should be changed back as soon as possible.
Whenever we clone a site on a development machine, the PackageStates.php will be rewritten shortly after and the order of entries will be all over the place, resulting in tons of changes, even though nothing has actually changed logically.
This brings up the question, should the file actually be under version control?
We experimented with ignoring it, but then, when deploying on a new machine, the site will not know which extensions to load. Which suggests to me that it shouldn't be excluded from version control. But then how should the information, which extensions to load, be transferred?
You can include the PackageStates.php to your version control.
You also can exclude it from versioning and generate it automatically during deployment process. typo3-console has a command for this:
typo3cms install:generatepackagestates
In older TYPO3 versions < 9 LTS, you have the option to install extensions based on conditions like context, host, system you can use
$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages'] = array('extension_builder','devlog');
in your AdditionalConfiguration.php.
Article about this topic at typo3blogger.de
If you have a TYPO3 composer installation, PackageStates.php is automatically generated when running "composer install":
https://docs.typo3.org/p/helhum/typo3-console/6.5/en-us/CommandReference/InstallGeneratepackagestates.html
Generates and writes typo3conf/PackageStates.php file. Goal is to not have this file in version control, but generate it on composer install.
I have authored a package (LoremIpsum) for sublime text 2, and submitted it to the package control list. It has been working fine, and I can see 10K+ people installed the package (on the community packages list). I have now updated it, and don't know how to inform the package control list.
Originally, I forked the package control list, added my package, and sent a pull request. I can not do that now, as I have no changes to make to the list - I just need to inform it that my package has updated (or do I? Does this happen automatically somehow?)
What should I do to make my updated version of the package available? How can I check that the correct version is published - and accessible?
You don't have to do anything. Package Control will grab the latest from your repository. Though if you added a custom packages.json file you will need to update that also.
Also, on the community packages list you can look at the version date (at v2013.01.20.07.51.55 at the time of writing this). When it "updates", the version number will be updated.
Edit:
Side note, you should add *.pyc to your .gitignore
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?