We've been using a Wordpress plugin called abase, to create on-the-fly forms and access MySQL tables directly. It's very easy to use for both the developer (minimal pseudo coding) and to the end-user. We'd very much like to keep using it in the long run, since it solves all our problems. But there is an issue. The developer no longer supports it and is stuck in PHP 5 code. So if I bring PHP to any version of 7, it breaks completely.
My IT headquarters require all servers to be on 7.3 or higher since there are security vulnerabilities with PHP 5.
Right now I have these options:
Try to find a way to migrate the script, although I think it'll be very difficult since the original developer is not available. I'm far from a PHP expert
Look for a replacement script, although I've done that already and haven't found a suitable script yet
Since is a server that is not pointing to the outside, maybe talk with IT and ask them to let me run PHP 5 on this server
So, what would you recommend? Are you aware of a similar plugin or maybe a script that I can use to replace it?
This is the plugin source: https://github.com/wp-plugins/abase
I am building a site platform similar to Wordpress that allows my users to download a .zip file, upload it onto their server, and be good to go.
I know everyone says eval() is evil - but the code will not include any user or variable input.
The benefit here is that updates will occur automatically. I can just change the code being grabbed on my server.
My clients using the code will have pretty low traffic sites - so I'm not worried about overloading their server. Most of the heavy lifting will be done by us.
Here's the basic code concept:
$code=file_get_contents("http://myserver.com/code.txt");
eval($code);
Is this a realistic option? What security holes do I need to worry about?
It's "realistic" in the sense that it will work, but at the same time it sounds like a sysadmin's nightmare. If you are meaning to have a client download and execute remote code every time a request is made, your clients are at your whim if the master server goes down or is unreachable at any point. It's now a mission-critical service you'll have to keep running forever for as long as your clients need it.
You list automatic updates as a benefit, but is it? In nearly every software platform, the features users depend on can change over time; function signatures can change, or functionality may be dropped entirely in favour of a more refined alternative. Since it sounds like you're writing some form of framework, can you guarantee that future versions will always be backwards-compatible? Not everyone is using the cutting-edge version of a piece of software in production for a reason -- they want what they are using to be stable. If an upgraded version of your platform rolls out overnight, and it breaks some custom code written by the client (at least one of them will try doing this, even if you don't want them to) or even, old, standard functionality that was deprecated but still worked with the previous release, how are they going to roll it back to a version that works?
It just sounds like something that will eventually incur a ton of technical debt.
I'm working from a remote site. In the jungle to be precise. My way of version control is for every upgrade, I will copy the whole current file to a new folder and name it based on the version and upgrade code on the main folder.
Is this right?
No. This is not a professional way of working with version control. You should use GIT, SVN o something similar. Your approach is only creating redundancies on your local machines and wont help you identify any changes made in different versions. GIT stores differences and therefore is helpful in keeping check of what exactly changed between two versions and is therefore actually helpful in debugging.
No.
Your approach will give you some kind of backup, but not professional version control. The difference is that your process is a lot more manual and does not document any changes you made. You cannot see when you made changes, or why.
Version control systems like git are vastly superior to that.
For most version control systems in general it doesn't matter where you are, or where your team is, as long as you have network in between.
A good approach would be to read up on git either on the official git-scm website, or maybe over at Atlassian. Those should get you started on how basic use works. If you want a bit more explanation of how its magic works, I suggest the excellent talk Git for ages 4 and up by Schwern.
Because deployment has been menitoned also, I would like to add that how you deal with your finished product doesn't really matter to version control. But the version control software can be used by deployment systems to get the newest version, which is convenient.
We have some web applications, and now these websites are being upgraded, not for the first time, but it is becoming very dificult to control the version for the users and for the developers.
We have many clients, some of they are running the same application, but they need to pay for upgrades. But, not all clients pay for upgrades, and because this we have some clients running one version and another clients running another version.
We have two ways, and we are researching for a third way:
Put the version in the path, like this: www\project\version\system-files
But this way became confusing for some users, because for they the URL became: www.website.com/app-version, and when the system is upgraded, the URL change.
Put the version in the function, like this: function V1_functionX()
When the function need to be upgraded, we create a new function called V2_functionX. But, this create a "fat" website, and the team did some mistakes during development, because we don't have "one development version", but "many versions to develop", and some functions are used in more than one website.
The very first way was abandoned a long time ago. We developed the web application, and "closed the version", and all requests was included in the upgraded version, that version when finished was "closed" too. But this was too slow too made corrections and deploy "small upgrades"
We talked about the way in another companies: they "shutdown" the website to upgrade the system. This will be probably our way.
But, if anyone have another idea to not shutdown a website for upgrade the application, we will be glad to listen.
Note: this is not about SVN.
You say you have different versions of your applications that must be maintained for different clients. I expect you don't need me to tell you this adds significantly to the complexity of your overall system, and thus your first priority is to reduce the number of versions you are maintaining in parallel.
API services have the same problem: a new version with more features is offered, but the old one needs to be maintained to give the new version time to stabilise and to give users sufficient time to upgrade their code. Your difficulty is similar. The first question I would therefore ask is whether it is possible to maintain only two versions.
If that is not possible, try at least minimising the number of concurrent versions: where a new version must be created, you need to encourage users to migrate from one version to another. (You've said you cannot unify your users onto one version, but without further information about your exact use-case, it is not possible to offer an independent view on that). So, perhaps one approach is to never maintain more than, say, five versions.
There are a number of strategies you can take to mitigate the complexity of the system you now have. Firstly, consider separating your code into a "core" of features that all versions absolutely must have. This will be common to all versions, so that if you fix a bug here, all clients benefit from the fix. This might be a visible feature (e.g. a product editing screen) or a framework feature (e.g. force SSL during checkout).
Your core libraries and client-specific functions could then reside in a set of libraries like so:
/project/core
/project/versions/1/Class.php
/project/versions/1.1/Class.php
/project/versions/2/Class.php
/project/versions/2.1.1/Class.php
/project/versions/...
(Class.php is of course an example - in practise there would be many class files here, each named appropriately.)
In this way, you do not need to call functions with a V1_ prefix, since that will require the replication of your version choosing code in a lot of places. It is much better to just load the library pertaining to the correct version, and as long as the function names are the same across all versions, you can just use the function name and your library loader will take care of the rest.
Another approach is to use plugins, like WordPress does. Where a plugin is added, it modifies some core functionality by adding new or different behaviour. The "middleware" design pattern may be useful here - the Slim framework (and undoubtedly others) uses this approach to add pre- or post-call hooks to an existing route handler, and thus offers a clean mechanism to edit existing functionality in a variety of combinations.
To summarise, your current situation is not just a management problem, but will cost you in slow development time and additional debugging. Whilst the above approaches will still be necessary to reduce some of the complexity, consider also:
forcing laggard clients to upgrade to one of your currently supported versions
giving an upgrade to laggard clients to the oldest possible supported version for free
Some additional thoughts based on new information. I had pondered whether splitting the code into separate repositories would help, one for each client. However I wonder if there is no guarantee that they would; even if you pull core features in using Composer, or a Git submodule, there is still the possibility of divergence between your latest core and your earliest client code. At some point your worst laggard client is going to hold back development on the core.
You can always leave this client on an abandoned version, but if they spot a bug, it is not worth back-porting a fix from your latest core, since that will cause you all the compatibility headaches you've been trying to avoid. Either they upgrade to a minimum client version that works with the latest core (and pay to do so if necessary) or they tolerate the bug indefinitely.
You've mentioned that each client gets his or her own database. That is helpful, up to a point, since it means that client versions are not entirely constrained with database schema decisions that have been forced by the core. However, this will still have a knock-on effect on how much code you can move to the core.
For example, let us assume that you have seven clients, and six of them have a User entity that has an email address, to handle password change requests (one client has a User entity without this field). This means that, if the awkward schema may not change, the core cannot assume that an email address is available. (In this trivial case it might be cheaper to upgrade the odd-one-out for free, so that more code can go in the core, rather than maintaining such a standard thing as a version enhancement).
Given the level of complexity, and since it sounds like you are maintaining this for the long term, I think you should set up some unit and functional tests. You'll need to split these into "core" and "per version" as well. If you find a bug, regardless of whether it is caused by feature versioning or not, write a failing test, and then fix it. You'll then have - at least in theory - a way to check if a change will impact on a particular client's version in a way you did not envisage.
We have this at my work :
Local dev website(SVN)
dev server where all developer test
Preprod where everything is Ok
Prod (rsync from preprod)
The rsync between 2 server is super fast, when we do a major update its in less than 5s
I'm doing a project for a comapny and I ran into a small problem using CakePHP 1.3. I found out that the problem was that the 1&1 hosting they currently have is using PHP 4, and my problem could be easily solved using PHP 5.
In the Control Panel of the hosting there's an option to change the Global PHP version from 4 to 5. However, in the same server where I'm developing this project, this company has a bunch of websites already running (like 8 or so), all of them with a high amount of PHP and MySQL code...
Is there any real risk to just switch the PHP version? Because of course I don't want to upgrade and suddently all the other websites stop working.
I don't know if there's an "easy" way to check the code in the server files. Making the switch and then trying everything again would be almost impossible, too much content to try...
Should I just deal with PHP 4? Are they going to have to upgrade no matter what? Any advice for this issue would be great, thank you!
There is definitely a risk of breaking something by simply dropping in PHP5. See the PHP 4 to PHP 5 migration index, most notably, the Backward Incompatible Changes section. Considering that PHP5 came out in, what... 2004? -- I think it's perfectly reasonable to have clients expect that you're going to keep your environment up to date and that clinging to PHP4 prevents you from doing so. In addition, not embracing PHP5 is going to just cause more problems like this as you continue to develop sites with 3rd party libraries that are being kept up-to-date. I.e., if they're expecting more work, this will just continue to happen more and more often.
Edit: Alternatively, if you simply can't switch them to 5, you might be able to get them to start another hosting account and set that one to 5 -- then use that to migrate the sites over one at a time.