I have recently taken on a php web developer position for a large firm. They have multiple sites that share much of the same content (mainly news articles). All the sites although written in PHP, the content is static and manually edited on all the sites when a news article is added or other information is changed. The "senior programmer" there is against using a cms for some reason, against upgrading to php 5, against installing mod_rewrite, basically I have to work within a very small parameter.
I have taken the first 3 weeks to write a whole lot of classes to make some sort of sanity out the mess, but I have to find a way to replicate this data in an easy manner. I am thinking something without the need of a database (the head guy doesnt want to decentralise data so databases anywhere other than the intranet are a no-no), I just want a centralised XML file or something, even if I need to hand edit it... any ideas???
Treat PHP as a templating engine, and have all the main pages pull the html marked up (or xml) articles from an RSS feed from one site.
Edit the feed to add a new article, add the marked up article to the main site, and it's all very, very simple, easy to understand, and scales.
No need to involved a 'real' cms, database, or anything.
-Adam
User one folder for all documents which your websites consume.
You could use CURL to access what you need over HTTP. Setting the CURLOPT_RETURNTRANSFER option to 1 will allow you to get whatever content you would like. XML, HTTP, etc.
Have one master site, on which the original content is created & edited.
On all others, use the Apache ErrorDocument handler in .htaccess to route 404 errors to a new php script.
ErrorDocument 404 /syndicate.php
In syndicate.php, take the uri (from $_SERVER['REQUEST_URI']), fetch the contents from the original domain and output it with a 200/OK header (so it's not seen as a 404).
$master_domain = 'http://master.com';
$master_html = file_get_contents($master_domain . $_SERVER['REQUEST_URI']);
if($master_html != '') {
header("HTTP/1.0 200 OK");
echo $master_html;
} else {
header("HTTP/1.0 404 Not Found");
}
The duplicate content will still be under the requested url.
If the senior programmer is against industry standard tools like CMSes, PHP5 (at least when considered against PHP3/PHP4 - no need for a language holy war), mod_rewrite, etc. it's time to involve management. Such an attitude is unacceptable.
Related
I'm managing a PHP-built site that uses a multi-tier Smarty templating system, with a main template including sub-templates, etc. The site itself has dynamic features of its own, including user profile displayed in the header, footer sitemap and menu dropdowns dependent on user access levels, etc.
I now need to put a vBulletin forum in the middle of it all.
One of my options is, of course, making vBulletin "look like" the site, with a plugin for a header and footer - but that is pretty much out of the question, as some of the site's features should override forum access entirely (maintenance periods, user access restrictions, occasional "splash page" redirections), we have JavaScripts and header bits, and then there's the part about whole-site templates I mentioned. Large bits of page code would need to be duplicated and that's something I'd really rather avoid.
So I went the other way and started including the forum's files through a "wrapper" PHP script, hoping to capture its output entirely in an output buffer, and put it into my template proper. I even simulated REQUEST_URIs and other $_SERVER fields, to make the forum think it's being run standalone. It fought me back fiercely, breaking out of ob_start()s and die()ing instead of returning at certain points, so much that I went back to the drawing board.
My other option is to hack my own site in a gruesome way, to provide a severed header and footer the forum would use - but then there'd be the bits and scripts to combine. Also I'd lose the ability to produce one page in one run, and having one-time generated content synchronized between the header and footer would become a nightmare.
What other options do I have? Do all the sites using vBulletin stick to simple headers and footers, or is there something obvious I'm missing?
Update: What would completely solve my problem would be if vB supported a "template wrapper" plugin, called with all of the forum's generated HTML buffered as a parameter; "here's the output, go ahead and do whatever the hell you want with it". But is there support for that? Or is it feasible to hack it in?
After some searching, I found that vBulletin 5 happens to have a hookFrontendBeforeOutput hook, which can operate on the entirety of the output produced by vBulletin's template rendering. I can thus create a plugin which will capture vB's output, correct it where needed, and feed it into my own template system for a final presentation - as well as fire the site's login and other logic mechanisms.
This forum thread has an example, demonstrating that very hook, albeit in a much simpler case.
I need to put together a simple/small website fairly quickly for internal use (no external access), which will contain a few forms and simple interactive pages.
I don't really want the maintenance overhead of a CMS, but so that each page has a consistent look and feel, etc, it would be useful to be able to have each page be based on a common template to wrap around the unique page content, to include the HTML head, title, site navigation, footer, etc.
One approach would be to include various snippets via PHP within each individual page, but that involves repetition in each page, and doesn't scale well if I decide I might need to substantially change things later.
The alternative approach would be to use the main DocumentRoot index.php file as the template, and instead have it include the requested page 'within' itself (so that each of the other pages is actually really only a partial file defining variables for the 'title' and 'body' (for the main page body content)).
I see that I can use $_SERVER['PATH_INFO'] to extract the desired file path (relative to the DocumentRoot) and $_SERVER['REQUEST_URI'] to get the whole request string (in case there might be any GET parameters); for the actual content of the index page itself I could have it include an alternatively-named file instead; and there must be some way in Apache rewrite rules that it would be possible to elide out the index.php from the eventual URIs, ..but I haven't yet thought through very much further than this.
I am sure that this must be a scenario encountered many many times before. I could well spend a couple of days trying to think this through and re-invent my own wheel, but I don't really have the time to do this, and it probably wouldn't be a very good use of it in any case.
Does anybody have some existing "quickie" code that would be "good enough" for this, or know of something "formally" published (at which point does a working quick hack become an actual software package?!)?
Thanks for any advice.
You could send your requested page as url parameter to your index.php, like 'index.php?page=requested_page' and include the following rule in your index.php at the position where you like to get your content
<?php
include("./pages/".$_GET['page'].".php");
?>
I'm not sure if any effort you will put into this will be less than the effort of implementing a simple CMS. Most systems have simple setups and do most of the work for you. Any time you save on not implementing a CMS will cost you later on maintenance. Don't use 'internal use' as an excuse to make bad software. Unless it's a one-time solution that will be disregarded in a few weeks, you (or another developer) will have to extend and maintain the software.
Redirect all requests to index:
RewriteEngine on
RewriteBase /
RewriteRule ^(?!index\.php$|(?:css|js|media)(?:/|$)). index.php [L]
Something like that will stop redirect loops on the index and send everything except requests to static content folders (change to suit) to your handler in the index. Access the URL via $_SERVER['REQUEST_URI'].
I'm basically trying to reverse-engineer a site made in Wordpress. My peer made our site in wordpress, and I would like to add some code to processing data from a form using the Contact Form 7 plugin. When viewing source, the form action is
/v2/wp/index.php/contact-us/#wpcf7-f57-p9-o1
Also I noticed that all the URL's of the various pages have text after the .php, which I don't understand.
http://.../index.php/information-for-sponsors/
In the first case, I don't understand how the "/contact-us/..." is processed. In the second case, I don't understand how "/information-for-sponsors/" is processed.
To implement this you need to look down the mod_rewrite option for Apache. It allows you to map urls and can be combined with php to get what you need.
For instance, I write a blog software before which translated the url .com/contact/ to .com/index.php?key=contact
Then using the key in php I returned the post with the title contact.
Google Apache Mod_ReWrite, it takes a while to undertstand fully and you need this option enabled on your host. Many Free hosts dont have this functionality enabled.
Though all the comments and answers above are absolutely correct, I am not sure, however, if you will understand any of them correctly.
Well, this concept is called URL Rewriting and is used for a variety of purposes such as improving ranking in search results, making readable keywords,etc.
There are lots of plugins in Wordpress which do this dirty work for you and there is also the Wordpress Codex(if you wish to write your own).
For your reference, I found this blog which will explain this better.
Smashing Magazine Article
Windows Server 2012, IIS 8; running a combination of Classic ASP and PHP.
I think I already know the answer to this one, but just in case I'm not as smart as I think I am...
I've got a car dealership client who has created a separate page for every make/model combination they offer, ~48 pages. They would like each one pointed to with a friendly URL, e.g.
theirSite.com/shop-chevrolet-camaro-inventory
=
index.php?p=123.
This means creating 48 separate rewrite rules, and while there's nothing inherently wrong with that, it bugs me to death. Had they consulted me, first, I would have advised them to create each of these as a template file, and I would have written a program to load them dynamically, using one page and one rewrite rule.
So, it is possible for the rewrite rule to somehow dictate a piece of the rewrite result? Taking
/shop-chevrolet-camaro
where camaro translates to page 123; corvette translates to page 124; cruze translates to 125; and so on? For SEO purposes, I can't point to an intermediate page and introduce a redirect, we have to hit the destination page directly as a rewrite.
Am I out of luck?
I think that you probably still can go with your idea here of just one page and one .htaccess redirect; Just a little different approach.
You can probably use include to bring their data from one of the 48 pages and display it on your "master" page. Now, to figure out which page to pull in, I wrote an answer to a similar question here:
https://stackoverflow.com/a/21714410/3293987
Hopefully this helps you. The basic premise is to take the "friendly" name (as it is appearing in the .htaccess and pass that to the script instead of the id number. Then, in your script, you'd do a lookup by the "friendly" name instead of the id. Then you can programmatically find which page needs loaded and use PHP's include to pull in the data.
As far as your concern of having an intermediate page for the redirect, you should not need to do a redirect with this solution; You can just load the data from the existing "peripheral" page on to the "master" page.
I hope that answer helps you.
So, currently I'm organizing my blog based on filename: To create a post I enter the name of the file. As opposed to storing the post in the database, I store them in PHP files. So each time I create a post, A new row in the table is created with the filename and a unique ID. To reference the post (e.g. for comments) I get the name of the current file, then search the entries table for a matching file name. The post ID of the comment matches the ID of that post.
Obviously this isn't the standard way of organizing a blog, but I do it this way for a few reasons:
Clean URL's (even cleaner than mod_rewrite can provide from what I've read)
I always have a hard copy of the post on my machine
Easier to remember the URL of a specific post (kind of a part of clean URL's)
Now I know that the standard way would be storing each post in the database. I know how to do this, but the clean URL's is the main problem. So now to my questions:
Is there anything WRONG with the way I'm doing it now, or could any problems arise from it in the future?
Can the same level of clean URL's that I can get now be achieved with mod_rewrite? If so, links are appreciated
I will be hosting this on a web host. Do only certain web-hosts provide access to the necessary files for mod_rewrite, or is it generally standard on all web-hosts?
Thanks so much guys!
P.S. To be clear, I don't plan on using a blogging engine.
As cletus said, this is similar to Movable Type. There's nothing inherently wrong with storing your data in files.
One thing that comes to mind is: how much are you storing in the files? Just the post content, or does each PHP file contain a copy of the entire design of the page as opposed to using a base template? How difficult would it be to change the design later on? This may or may not be a problem.
What exactly are you looking for in terms of clean URLs? Rewrite rules are quite powerful and flexible. By using mod_rewrite in conjunction with a main PHP file that answers all requests, you can pretty much have any URL format you want, including user-friendly URLs without obscure ID numbers or even file extensions.
Edit:
Here is how it would work with mod_rewrite and a main PHP file that processes requests:
Web server passes all requests (e.g., /my-post-title) to, say, index.php
index.php parses the request path ("my-post-title")
Look up "my-post-title" in the database's "slug" or "friendly name" (whatever you want to call it) column and locates the appropriate row that way
Retrieve the post from the database
Apply a template to the post data
Return the completed page to the client
This is essentially how systems like Drupal and WordPress work.
Also, regarding how Movable Type works, it's been a while since I've used it so I might be wrong, but I believe it stores all posts in the database. When you hit the publish button, it generates plain HTML files by pulling post data from the database and inserting it into a template. This is incredibly efficient when your site is under heavy load - there are no scripts running when a visitor opens up your website, and the server can keep up with heavy visitation when it only needs to serve up static files.
So obviously you've got a lot of options when figuring out how your solution should work. The one you proposed sounds fine, though you might want to give careful consideration to how you'll maintain a large number of posts in individual files, particularly if you want to change the design of the entire site later on. You might want to consider a templating engine like Smarty, and just store post data (no layout tags) in your individual files, for instance. Or just use some basic include() statements in your post files to suck in headers, footers, nav menus, etc.
What you're describing is kind of like how Movable Type works. The issues you'll need to cover are:
Syndication: RSS/Atom;
Sitemap: for Google;
Commenting; and
Tagging and filtering content.
It's not unreasonable not to use a database. If I were to do that I'd be using a templating engine like Smarty that does a better job of caching the results than PHP will out of the box.