I have a Movable Type site running MT 4.38, and I was wondering whether I should upgrade to 5.
For a while, MT 4 and 5 seemed to have been developed concurrently, but now I only see activity in MT 5. Has MT 4 been abandoned?
The person using the site is change averse, so I only want to upgrade if it's absolutely necessary (i.e. security issues).
Thanks
Yes. Movable Type 4.38 has a patch for a security vulnerability which you should be sure to apply. But beyond that, you should absolutely upgrade to Movable Type 5.2.3.
The big reason is that Movable Type 4.38 will be end-of-lifed on December 31, 2013. This means that there will be no security updates for Movable Type 4.38 after that date.
Movable Type 5 has a number of great new features that are huge improvements over MT 4.38:
New and improved Rich Text Editor based on TinyMCE
Revision history on the most-used objects in the CMS
List-management framework enhances Movable Type's ability to manage large amounts of data inside the CMS
Sortable categories and folders
Template tags for things like mt:EntryPrimaryCategory
Enhanced multi-blog support
Huge support improvements for Webkit-based browsers (Safari and Google Chrome) as well as IE 8 and 9
Login failure detection, allowing either account or IP address lock out
With all due respect, no one should be running a version of Movable Type that is no longer supported with security patches. It's foolish to think that any one person can know all of the possible security issues in an older version of a Content Management System such as Movable Type.
Yes, MT4 is no longer developed. It still receive security patchs every few months, but there will not be a new version.
As for what you want to use, MT4 and MT5 have a different set of plugins. So if you want to upgrade, check that the plugins that you need support MT5 or have a MT5 replacement.
Upgrading would work without any problem if you are not using 3rd party plugins.
If you're using 3rd party plugins, you might encounter compatibility issues because the v5.x architecture is much different than 4.x.
Before considering to upgrade to v5.x you may like to check your 3rd party plugins and see if there is a version that works with v5.x.
Another thing to consider is to clone your installation and try to upgrade it on a different domain/folder or on a stage server where you could check that everything works before upgrading your live installation.
Alternatively you could order a professional movable type upgrade service from:
http://www.movabletypeupgrade.com/
Related
Can someone tell me why the SAPUI5 version "1.56.16" stopped working? (using CDN).
I know they have been removing some outdated versions, but, I don't see this one on the list.
Or maybe I don't understand which ones are getting removed...
Versions List
Thank you!
You actually answered your question yourself: You can find this information on the SAPUI5 Version Overview Page.
If you check there table SAPUI5 Versions Maintenance Status you can see that 1.56 is an interim version as it never had long term maintenance. So this means this version went out of maintenance when 1.58 was available or rather in case of consumption via FES when 1.60 was available (which was around Q1/2018).
In column End of Cloud Provisioning you can see that the removal of 1.56 was scheduled for Q1/2022. That's why also 1.56.6 is not available anymore.
The schedule when a patch will be removed can be found below in table Available SAPUI5 Versions on SAP Business Technology Platform, but only as long as they are available. As a rule of thumb patches will be removed if they are older than one year or rather with the End of Cloud Provisioning of the respective SAPUI5 version.
It is important to understand that the removal of outdated SAPUI5 versions will happen at regular intervals, each and every time when a patch is older than one year or rather a version is out of maintenance for one year.
I've been given a request to upgrade an application running under filemaker pro 6.5.
It's connected to some serial devices and uses plugin-component (troi) to solve the communication (rs232).
It's running in a closed network attached to a remote FM65-database.
Will FMP12 be able to run the application w/o a lot of recoding or has things changed too much?
Regards,
/t
Simple answer, yes.
First of, there was no FileMaker 6.5. It went from version 5 to 5.5. to 6 and then 7. When version 7 was released there was a major update in fileformat for the databases, introducing multiple tables in a singel file and a new relationship schema.
Between version 11 and 12 there was another big update in fileformat. The bigest change being that the layouts are now rendered as HTML/CSS using WebKit.
Even though a lot has happend since version 6 FileMaker Inc always try to be backward compatible. As far as I know, no functionality has been removed, at least nothing vital.
Troi Serial Plugin works with FileMaker 12 but you will need to upgrade the plugin. you can read more about the changes for the plugin, pricing and download a demo at
http://www.troi.com/software/serialplugin.html
You can also download a 30 day trail of FileMaker from http://www.filemaker.com
Thus you can easily try the entire setup for free before doing it for production.
The only thing you probably will have to adjust is the function call for the plugin Troi Serial, but that should be easy!
Hope this helps
I'd recommend you use Metadata Magic to analyze the FP5 solution.
There are some script steps that can be problematic when upgrading. This will give you a comprehensive report of what issues to look for and where to find them. It's not uncommon to find script steps that need to be reordered or changed.
I wish to create a document repository for my company. Reason is because my company have many documents and they did not have a version tracking in place. This means everyone is using different version all the time.
Plone is something new to me and i got to know from a good friend of mine. And too bad he is not around anymore to answer my question. I believed in him and i wish to materialize his idea, to use Plone as a document repository for my company.
I have install Plone and manage to view the default Plone page, add all company's username and change the logo to my company's logo. And now the biggest question is, how to setup the document repository? What i have in mind was to create a "page" for the user to add files, download files, search for files and read its description.
Any lead for me to go about?
Reusable,
Same problem here. We started to use Plone as our main DMS 4 weeks ago (inserting existing docs at present).
For working copies, we use iterate (insert plone.app.iterate under eggs in your buildout.cfg).
For versioning, Products.CMFEditions. I believe this worked out of the box.
For creating new workflow, look into plone.app.workflowmanager and read the docs.
In a previous question we asked, we were still looking at Dexterity which has alot going for it but eventually we decided on adapting an existing content type based on Archetypes.
As for inserting files, as long as the description is ok, they will be found through the in-built search functionality, but you might consider using Iterate mentioned above to make sure that nobody is using the same file twice.
As your new, as I am, the docs seem hard at first but are actually quite good.
And this book is still giving me the foundation we need to keep adding functionality.
Good luck
I think, you should get pretty far with vanilla Plone installation, without developing your own extensions or other customization add-on-products. Therefore, I'd recommend you to start with Plone 4 User Manual to find out everything you could do out-of-the box.
As #Speediro mentioned, versioning support comes built-in for the main content types (and you don't actually see CMFEditions mentioned anywhere), but it's not activated for file uploads. Although, as briefly mentioned in the manual: Content items can be configured to have versioning enabled/disabled through the Site Setup → Plone Configuration panel under "Types".
Working Copy Support (plone.app.iterate) should also be there already waiting for activation on Site Setup's add-ons-panel.
Yet, before the Plone Collective (=community) Developer Docs or Professional Plone 4 Development, I'd recommend Practical Plone 3. It has a bit outdated graphics (because it was made for Plone 3), but it's great next step after the user manual. E.g. how to define content rules to send e-mails notifications for content updates (still through the browser without coding). Or how to create custom forms using Products.PloneFormGen.
When you really need to write your own code, it'd be time for Professional Plone 4 and the Collective Docs.
If you can't have a developer to manage your stuff, I would recommand to stay on official Plone, no custom code and use only widly used addons.
I mean:
stay on the default theme (sunburst)
use the default plone content types
only customize the logo
activate plone.app.iterate in the addon controlpanel
do not play with workflow because they need to know what you are doing. by default a file has the visibility of it's folder. It mean if you can see the folder you will be able to see all files inside. You can just activate default worklfow for files under the ZMI.
Use collective.quickupload addon
Your database will going really fast to a huge size because Plone is doing indexing and indexing means lot's of spaces. So you will have to handle this as system adminstrator;
I am having much confusion over the process of upgrading version numbers in dependent plug-ins, features, and products in a fairly large eclipse workspace.
I have made API changes to java code residing in an existing plug-in and thus requires an increase of the Major part of the version identifier. This plug-in serves as a dependency to a given feature, where the feature is later included in a product. From the documentation at http://wiki.eclipse.org/Version_Numbering, I understand (for the most part) when the proper number should be increased on the containing plug-in itself.
However, how would this Major version number change on the plug-in affect dependent, "down-the-line" items (e.g., features, products)?
For example, assume we have the typical "Hello World" setup as follows:
Plug-in: com.example.helloworld, version 1.0.0
Feature: com.example.helloworld.feature, version 1.0.0
Product: com.example.helloworld.product, version 1.0.0
If I were to make an API change in the plug-in, this would require a version update to be that of 2.0.0. What would then be the version of the feature, 1.1.0? The same question can be applied for the product level as well (e.g., if the feature is 1.1.0 OR 2.0.0, what is the product version number)?
I'm sure this is quite the newbie question so I apologize for wasting anyone's time and effort. I have searched for this type of content but all I am finding is are examples showing how to develop a plug-in, feature, product, and update site for the first time. The only other content related to my search has been developing feature patches and have not touched on the versioning aspect as much as I would prefer. I am having difficulty coming into (for the first time) an Eclipse RCP / PDE environment and need to learn the proper way and / or best practices for making such versioning updates and how to best reflect this throughout other dependent projects in the workspace.
If you would like to apply the same versioning systems to feature and product, then you would set feature and product to 2.0.0 when one of the plugins go to 2.0.0. That would communicate to whoever is consuming your feature or product that there is a breaking API change inside it somewhere.
On the other hand, there is no requirement to apply the same versioning convention. You can version your bundles following that convention to properly communicate your API changes and then turn around and use more marketing-sensible versions for product/feature. Keep in mind that user will see product/feature version more than they will individual bundle version.
I've seen it done both ways effectively. There isn't really a right or wrong way on this.
I have an third-party applet that requires JRE v1.5_12 to work correctly. THe user is installing JRE v1.6.07 or better. It used to be with 1.5 and below, that I could have multiple JRE's on the machine and specify which one to use - but with 1.6 that apepars to be broken. How do I tell the browser I want to use v1.5_12 instead of the latest one installed?
For security reasons, you can no longer force it to use older JRE's. Say release 12 has a huge security hole, and everyone installs release 13 to patch it. Evil java applets could just say "run with release 12 please" and then carry out their exploits, rendering the patches useless.
Most likely you have some code with security holes that the newer JRE is blocking, because it would cause a security risk. Fix your code, should be pretty minor changes, then you wont have to worry.
See this page for more info on the change.
The new applet engine (that will be shipped with 1.6u10 when Sun gets around to officially shipping it) gives you a tremendous amount of control in this area. It's going to take awhile to get enough systems on 6u10 to where you can actually rely on the functionality (unless you are corporate) - but it is coming (seems like it's about 5 years too late).
Here's a JavaWorld article describing this at a very high level: article text
6u10 also has a deployment toolkit that provides super easy to use javascript snippets that you can include in your applet deployment pages. These snippets handle JRE version checking, user notification, JRE downloading on demand, and a number of other things that are otherwise a hassle (not impossible, just a pain). The deployment kit has been designed to fail gracefully, so it does amazing things if 6u10 or above is installed, and drops back to decent behavior for older JREs.
One really, really nice thing about the new applet engine is that it runs in a separate process space from the browser. This has a couple of very big advantages, including the ability to have multiple applets running in different versions of the JRE (yes, you can specify different required JREs, including restrictions on how old and how new of JRE you support - the applet engine will re-use JREs if it can, but it has the ability to start up a different one if it needs).