Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 10 of 10
  1. #1
    Regular Coder
    Join Date
    Mar 2012
    Posts
    168
    Thanks
    5
    Thanked 11 Times in 11 Posts

    If you built your own simple CMS...

    I've been taking on online courses to learn PHP and right now the project is to build a simple CMS. I get that and I know the basics about managing tables and databases, but what if I wanted to 'package' that CMS for other people? How do you transfer a cms with its tables and everything packaged and ready to go? Is this simple to do? Thanks!

  • #2
    Regular Coder Custard7A's Avatar
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    286
    Thanks
    32
    Thanked 33 Times in 33 Posts
    You can use files to run SQL. I remember once I used another person's code that required some MySQL tables, and it came packaged with a .sql file. All I had to do was go into phpMyAdmin and select "upload file", or "create from file", or something along those lines (It was a while ago!). I believe it's just normal SQL queries in the file. There are other options as well, like including a normal web-page file and directing a first-time view of it to create the database. I think if you have so far been creating your database structure with the visual interface provided, you should begin working on creating these things with SQL queries. SQL in some manner seems to be the best way to package table setups and other database structure stuff. Not that I have had much experiance with trying to package my stuff.

    Other things you might want to become aware of when making code to share is server environment issues. Dealing with PHP you might want to be checking the status of each feature you are using against the documentation. A lot of changes have been made per version 5.3 in particular it seems, but there are still many hosts that are running pre 5.3 PHP setups. Either avoiding the shiny new toys, or being aware of (and broadcasting) the minimum version your shared code will work on can go a long way to making it more professional (and 'bug'-free for other people). The same might be said about checking your php.ini settings, and being aware of any non-defaults with that.

  • #3
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,344
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    Bah, Custard you're still making that harder than it needs to be. Many people don't even know how to use phpmyadmin.

    Run this in phpmyadmin to test and then use it in your setup scripts to create the tables:
    show create table <tablename>

    This will show you the SQL to create the new table with the same structure. At this point you can via your php, insert your first rows of data as part of the setup - eg an admin user.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #4
    Regular Coder Custard7A's Avatar
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    286
    Thanks
    32
    Thanked 33 Times in 33 Posts
    One time I wanted to make my scripts smart, so that if they tables didn't exist they would be created on the spot. I never did it, but that might be very nice for running script out of the box or switching databases. That would leave a band-width footprint that would do nothing 99% of the time, I suppose is the drawback, but throw in autoloading and it doesn't seem as horrible.

  • #5
    Regular Coder
    Join Date
    Mar 2012
    Posts
    168
    Thanks
    5
    Thanked 11 Times in 11 Posts
    Thanks y'all, that helps a lot.

    So lets say I create a set up page, titled setup.php and I tell people that are using my cms to go to root.com/setup.php and this page makes the tables and inputs initial data and sets up maybe even the admin user/pass. Then I could use the unlink("setup.php"); function to delete the setup file at the end of setup. Would this be a good way to do this?
    Last edited by KULP; 12-26-2012 at 06:22 PM.

  • #6
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,344
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    Quote Originally Posted by KULP View Post
    Then I could use the unlink("setup.php"); function to delete the setup file at the end of setup. Would this be a good way to do this?
    Your script won't be able to delete itself. Your best bet would be to redirect users to the main page with a parameter in the url (eg setup=1) which tells the main script it can delete the setup script. That or you get the users to delete it manually via FTP.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #7
    Regular Coder
    Join Date
    Mar 2012
    Posts
    168
    Thanks
    5
    Thanked 11 Times in 11 Posts
    Quote Originally Posted by tangoforce View Post
    Your script won't be able to delete itself. Your best bet would be to redirect users to the main page with a parameter in the url (eg setup=1) which tells the main script it can delete the setup script. That or you get the users to delete it manually via FTP.
    Ah, so a file can't delete itself, you have to have another file delete it. Alright well that sounds simple enough! Safe I assume as well? Building a CMS is kind of fun... >

  • #8
    Senior Coder
    Join Date
    Apr 2011
    Location
    London, England
    Posts
    2,120
    Thanks
    15
    Thanked 354 Times in 353 Posts
    Quote Originally Posted by KULP View Post
    Ah, so a file can't delete itself, you have to have another file delete it. Alright well that sounds simple enough! Safe I assume as well? Building a CMS is kind of fun... >
    Suppose they need to run set-up again? Might it be preferable to just rename the file? Or perhaps the set-up sequence could check for the existence of a table to know that it has already been run? In which case, the user would need to delete the database or table(s) to re-run the set-up sequence.

    Just a suggestion
    "I'm here to save your life. But if I'm going to do that, I'll need total uninanonynymity." Me Myself & Irene.
    Validate your HTML and CSS

  • #9
    Senior Coder
    Join Date
    Feb 2011
    Location
    Your Monitor
    Posts
    4,344
    Thanks
    60
    Thanked 527 Times in 514 Posts
    Blog Entries
    4
    Quote Originally Posted by AndrewGSW View Post
    Suppose they need to run set-up again? Might it be preferable to just rename the file? Or perhaps the set-up sequence could check for the existence of a table to know that it has already been run? In which case, the user would need to delete the database or table(s) to re-run the set-up sequence.

    Just a suggestion
    No you never leave setup files in place for attackers to misuse. NEVER. This is the very reason forums like PHPBB refuse to operate if the install directory is still in place. They effectively shut down to prevent abuse of the NON PASSWORD PROTECTED setup script.

    Always delete the setup script because otherwise you're going to come a cropper when someone has abused it and setup their own stuff on your server. It's also too easy for the site owner to re-use it and screw things up. Setup once and leave it be.
    See my new CodingForums Blog: http://www.codingforums.com/blogs/tangoforce/

    Many useful explanations and tips including: Cannot modify headers - already sent, The IE if (isset($_POST['submit'])) bug explained, unexpected T_CONSTANT_ENCAPSED_STRING, debugging tips and much more!

  • #10
    Regular Coder Custard7A's Avatar
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    286
    Thanks
    32
    Thanked 33 Times in 33 Posts
    That's another good point for when you're sharing code. Bad people have full access too, so they can download the scripts and look for any point of weakness. You have to be careful that you're not putting everyone who might use it at risk.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •