I have looked and looked all over to find a way to make something similar to PhpBB's automod system they use for their software.
I cannot seem to find anything similar to this with the whole xml find and replace code updater and mod installer.
I may just be typing in the wrong keywords in Google, but does anyone know of any system like this available before I start trying to make my own?
EDIT: I mean more like a code updater. For example find and replaces in a php file.
FIND:
?>
ADD BEFORE:
echo "this is text added before the ?>";
I realize this could be done with str_replace but there is surely a system out there that already does this reliably.
The reason that a system doesn't exist outside of phpBB is because it's an incredibly poor way to manage modifications. Your question does not make it clear what you want to gain from this, but since it is your own code, you should definitely not look to copy something so awful.
For “patching” code
If you want the ability to apply updates to your code, then you should look at handling it through version control. For instance, you could develop and test in a local git repository, and once you are happy, push the changes to the server. You have many options here from a basic update script to a fully-fledged Continuous Integration solution.
phpBB have implemented a solution for patching code on your live site via a Web interface, which has many issues with security, verifiability and maintainability among others.
For exposing “plugin” functionality
If you want the ability to register plugins in parts of your code, then you should architect your code as such to allow it to be handled easily. Wordpress, MediaWiki and other projects can help you write such a structure.
Related
I am new to Github, and want to find some good written PHP website application source code to read. But simply type 'php' as keyword and search on Github is not that effective. Is there any better way to do it?
Also, are PHP frameworks source code good to read and learn?
I think on github there is also a lot of bad written code. I can tell you that maybe working with an CMS might be something for you. While creating Plugins for CMS systems you learn the CMS itself part by part. This way you may understand why things are how they are.
In general, noone simply starts reading Code. You read Code to understand how you interact with an external system.
I'm developing a distributed environment, mostly in PHP.
A lot of the projects that I have share some of the same code. For example my logging code (based on log4php but with some custom additions).
I can just copy-paste this code in every project, but naturally, if I change anything in it I need to re-paste it everywhere and 'hope' it doesn't change anything.
Obviously not a good way.
Now, I was wondering: what is the best and simplest way of sharing this code?
I'm hoping there is something as easy as making your own private PEAR-like channel? Do people do this for this use case? Or is there an ever easier way? I rather not start with inter-dependent repositories etc. If it matters though, I use Mercurial for versioning.
Thanks all.
Perhaps the best way (I am using too) is to host the common code in a versioning system such as Git or Mercurial or SVN and checkout this code in each related project. As long such a project does not have updates you can continue to work on your common code. In the case you want to touch a project again that utilizes the common code, you need to perform a source code update or pull. Then you update your project sources according to the changes of the common source base.
What about include_path PHP directive?
Just add include_path, for example /usr/share/php5/
and include your file like yourfile.php from each project
Use Git or Mercurial for that. In both of them, you can create sub-modules or sub-repositories.
http://kernel.org/pub/software/scm/git/docs/git-submodule.html
https://www.mercurial-scm.org/wiki/Subrepository
I'm thinking about rebuilding my website from scratch, but this time, using a CMS. Everywhere I turn people tell me to use a cms, but it's only now I'm really considering it. My site isn't too complicated. Is this a good idea in terms of workflow? I'm the only person who will edit the site, so if it's just a matter of workflow and efficiency, should I just convert now before it gets really big?
Sure, a few come to mind.
Deployment complexity. Many CMSes require a database, which means running a database process somewhere, and backing that up, as well as the rest of the code and assets for the site.
More space will be required to hold the CMS code for the manager, framework, libraries, etc.
Bloat could come into play, the CMS may, and likely would, implement features you have no use for.
Additionally any CMS will have some kind of limitations, some things will be more tricky to do than others when compared to a mostly static site.
Just read the code. That's often all the arguments you need. (If your needs are really simple and you don't need plugins and you don't need to write any code yourself I'd still use a CMS, though)
If your site is mainly a design showcase, and doesn't have real content in it, then a CMS will only get in your way and make things harder.
Otherwise, it will mostly be of help.
Along with everyone else's statements. If it's just a small site you don't necessarily need a CMS, but if you are wanting to use a CMS for client projects in the future, why not start now.
Deployment. If you're doing some big changes to your site or testing something, you'll probably want to try it out locally with a development copy of the database. Once you're done, how do you get everything to the live site without overwriting, say, comments that were made on the live site since you created a development copy?
Specialization. CMS's are great for some things, but they're bad at others. What if you want to add more complex functionality to your site? It might be a plugin or module at first, but soon you're writing all this code and you realize you should have just used a framework and built the CMS part yourself.
If it's a simple static site with a single editor and without any aspirations of using complicated functionality and you feel confident enough in your web language of choice, then go for it. Even if you don't feel confident enough, it should be a good challenge.
Write some minor templating so that you can separate your code from your design, have some simple way of adding articles or blog posts or whatever - it could be as simple as including text files from a directory.
Using a CMS, even in their modern and quite usable state will require more resources, hardware-wise. and will probably have a steep learning curve. It will also require maintenance and dilligent security patch application as new vulnerabilities appear. On the other hand a CMS can get you up and running with a basic site quickly, and grow with your needs if you feel like enriching it, as you get to use its large variety of ready made plugins and extensions. You want blog comments with users logging in via OAuth? No problem. RSS? There's an extension for that.
Bottom line is, if this is a simple static site with a single editor as you describe it, it should be trivial to set up some code to run it. You'll spend as much time on its template design as you would on customizing a CMS's template, avoid the initial learning curve a CMS requires, and not worry too much about the resources and maintenance a modern CMS requires. You will, however, be limited in functionality and future ideas by what you can write or integrate yourself.
It depends somewhat on the purpose of the site.
If it is a means to an end of getting information posted on the web, then adopting something like WordPress will quickly get you going, and provide lots of extra functionality that would take a fair amount of time to build in - e.g. stats, feeds, remote publishing etc. There are a few basic steps you'll need to go through setting up self-hosting on a shared web-hosting package e.g. creating the DB and unzipping the files etc but fairly straightforward really. And the time you save administering your website can be focussed on other things where you're making a difference or doing something different to everyone else.
However if your purpose is in part the learning experience of developing the functionality or you have unusual requirements that aren't in a standard CMS, then there is an argument for developing your own.
I have developed an application and now I would like to hire some programmers to work on several pieces of it to upgrade and tweak it.
I have read other questions/answers here but they are mainly about obfuscating the code which is something I do not want to do (as I need them to read it and tweak it).
What I'm basically asking is, what is the best way to structure my code so I will have to expose only what I have to?
A good example for me is a webapp called RightNow which I'm developing for at work, what they do is they let you play around with all the widgets (you can create/edit/remove any widget) but the core of the application is in folders I do not have permissions to.
After you do your coding on the widgets, you then 'deploy' the application and it goes live. I have no idea what the deployment actually does behind the scenes, but this is one practice (not sure if it's the best) which allows the application owner to have control over the core of the code but still allow development for it.
Is there a better way? what do you think?
First you can use a version control software like SVN for example.
and then you can have copies of the code, one for testing and one for the your programmer. When the programmer is done changes and tweaks, the testing code gets updated first and when the test are done the live application gets updated.
you can obfuscate your core classes(ones that you don't want to expose). and other developers can include and use them at the same project as long as you provide a nice api to your classes.
I have a need to create a library of Object Oriented PHP code that will see much reuse and aspires to be highly flexible and modular. Because of its independent nature I would like it to exist as its own SVN project.
I would like to be able to create a new web project, save it in SVN as its own separate project, and include within it the library project code as well. During this process, while coding the web application code and making commits, I may need to add a class to the library. I would like to be able to do so and commit those changes back to the libraries project code.
In light of all this I could manage the code in two ways
Commit the changes to the library back to a branch of its original base project code and make the branch name relevant to the web project I was using it with
Commit the changes to the library back to the original code, growing it in size regardless of any specific references that might exist.
I have two questions
How can I include this library project code into a new project yet not break the subversion functionality, i.e. allowing me to make changes to each project individually?
How I can keep the code synchronized? If I choose the first method of managing the library code I may want to grab changes from another branch and pull it in for use in another.
EDIT - I realize I can simply check out these projects individually and commit/update them individually as well, but then how can I include them together as a single project? To be more clear, how could I create a web project that includes the library code as a unified subversion project in consideration of the points I elaborated on above?
I think you can use svn:externals to achieve what you want. It will pull the library project into your website project and update it whenever you update your working copy. The only thing is you cannot commit back to the library in the same commit as you project as described in this question How do I checkin to local copy AND svn:externals subdirectories in one commit?.
Option #1 looks like the right way to go.
I think you should expect to keep separate branches of the API project for any of your sites that have site-specific modifications to the shared API. Of course, you don't need to create the branch upfront, just checkout the 'trunk' and make sure you branch before you commit any site-specific changes.
There are a couple of articles on branching/merging that I have used in the past that might help you out:
Streamed Lines: Branching Patterns for Parallel Software Development
MSDN Branching and Merging Primer
However, there are some aspects of your 'two questions' that are a bit confusing/concerning. Hopefully I'm misinterpretting what you've said, but keep the following in mind:
With your first question, I think you might be getting caught up on the physical location of the source code on your development machine and how your repositories will be structured (hint: treat the two separately).
In your second question, you mention specific references and it sounds like you might be thinking of making your API in some way dependent on the website source (hint: bad idea for an API).