Exposing a web service through WordPress - php

I'm creating a new plugin for WordPress that requires an outside website to use a web service. For instance, if there are two sites, A and B, the plugin will be installed on A with all associated data stored in the WordPress database for Site A. Site B will use the web service to grab data in XML format from Site A.
Is this possible? What would be the most secure way of pulling this off?
I could just have the web service as a PHP file in my plugin, but that's going to require the outside domain to hit something like:
http://www.example.com/wp-content/plugins/plugin-folder/web-service.php. It seems like a bad idea to expose the level of depth of the WordPress setup.
I could have my plugin create a few files in the root so that the web service call would be to http://www.example.com/web-service.php, but having my plugin install stuff outside of the plugin directory also seems like a bad practice.
Another thought: Could I put the file in my plugin folder, but add a line in file .htaccess to make http://www.example.com/web-service.php go to it?
What is the best, most secure way to go about this?

I would set up a rewrite rule in .htaccess to let the user get to your code without knowing where it is. I don't think there is an easy way to add specific routes to the WordPress front controller, but you could see if there is an action or filter to do that.
Here's a post on adding routes: How can I create custom URL routes?

In my personal opinion, if I installed a WP plugin and you created a new file in my root directory, I would either delete the file or the plugin all together. I would also try to avoid adding a .htaccess file. This would again make me suspicious.
What I would do is, upon install ping a file on Site B (your site) that captures the location of the plugin folder on Site A (their site), because WP might be installed inside of a directory and not at the root. Then you know where the "web-service.php" file is located. Then you can just hit that file whenever you need. There is no reason for .htaccess rules, or creation of new files.
Just a suggestion :)

Related

I wonder if Wordpress uses any type of configurational inheritance from main site to the nested site

With Wordpress I had only some experience in setting up different sort of plugins, never dealt with how it's done on system and engineering level. Now I'm going to move my site from host to another host and need some advise over the following thing:
with my existing hosting I host 2 web sites: root one (andrtsa.com) and one I created later (oksana.photography) that I noticed is shown with its own content under [public_html]. I do not need old root site, it's outdated, I only want to migrate new one in subfolder. I wonder If I can just take (copy) whatever I have in root folder of my site (folders like [public_ftp], [perl5], [.cpanel] etc), and I'm removing everything from public_html except [oksana.photography] folder which whole content I copy to its parent [public_html] folder like on the picture:
I wonder if nothing. My only concern is that Wordpress (php) might use some form of folder to subfolder inheritance, like if I remove something important that is in public_html and missing in [oksana.photography] configuration file or something I could be in trouble, not sure though if anything like this is used in Wordpress. Please advise

How to run multiple subdomains on the same Yii engine?

I would like to structure the website not using url-folders, but rather subdomains:
not my.com/xyz/page1
but rather xyz.my.com/page1
they would share the same design, same layouts and reuse large part of the codebase.
Is it possible to configure URL manager so that both main domain and a subdomain are served using the same codebase?
P.S. Yii version is 1.1.
We use this setup at work actually. What you do is parse your url in the index.php file. Break it up. Based on the first word up until the dot... that can be the name of your folder in the protected/config folder. Make a copy of all of the files currently in the config folder and put it into this new one. So the file structure is /config/subdomain/allfiles here... and /config/subdomain2/allfiles... etc etc. And make sure that the yii app gets made using the correct config by oarsing the url and using the subdomain to locate the folder. You can use different params... dbs, etc etc. But the same code.. and file base for all.

Building a CMS to For Website

I have my main site kansasoutlawwrestling.com which will be using Codeigniter, and then I am also creating a CMS for myself that is a separate entity which will be located at kansasoutlawwrestling.com/kowmanager.
My CMS will use different CSS, javascript, and image files, so I'm wondering if I should just have two different installs of CI. I tried looking at PyroCMS, but there's way too many folders and I was having a problem understanding its file structure. What is the proper set up for this is?
The basic structure of Codeigniter is that you have 2 folders and 1 file in your root folder:
root/application/
root/system/
root/index.php
Now, obviously, you might have many more files and folders in there as well, but these are the basics upon which every Codeigniter app runs.
What do each of these do? To begin with, every page request starts at index.php. This page set's up some configurations and some constants, and then hands over the reigns to Codeigniter.
Where is "Codeigniter" located? That would be the system folder. This folder should never be touched, by you or anyone else. Everything pertaining to your app is stored within the application folder. This includes all your configurations, your controllers, your models, your views, even your library extensions (although you could store other stuff outside this folder, like images/css/js/fonts etc.).
So, the correct way to set up shop would be:
root/application/
root/system/
root/index.php
root/kowmanager/application
root/kowmanager/index.php
But, you have to inform your kowmanager's index.php that the system folder is not located in the same directory. So, within the index.php (inside of kowmanager), at around line 25, you should see this:
$system_path = "system";
Simply change it to:
$system_path = "../system";
and you're done.
Now both your apps (your main site and you CMS) will be sharing the same Codeigniter base. When the time comes to update CI, you'll do that once within the main system folder...
I've done several Codeigniter CMS's and taken both routes:
Integrated (shared application files and assets)
Separate installation (only shared system files, if any)
At first I liked the convenience of the integrated approach: when I needed a custom library or icon file for the front and back end, it was available without duplication. I've since changed my mind.
My opinion now, after 4 years or so of working on these, is that the benefits of having an integrated CMS is short-lived.
90% of the code is in the back end, so you end up with lots of helpers, libraries, etc. that are only used for administration.
Any shared resources that you need to tweak can end up working great on one side, but breaking the other, or being overkill/useless.
Models tend to be bloated for use on the front-end when they are full of code that's only used for the back end.
Shared templates, js, and css files almost never work. The control panel probably doesn't need to work in IE{insert version here}, but your front end should.
It makes updates and upgrades to either end sketchy, unless you know exactly what you need to update and what not to touch, and where you may have made customizations for a particular site's front end that should not be altered.
Auth logic is much easier when your admins and regular users aren't in the same bucket
Separate installations are easier to set up, and they can be "tacked on" to an existing site rather than having to integrate it.
My advice: Go with a separate installation.
If I were you, I would probably not go the separate applications path. If you're sharing things like code that renders a page or logs a user in, you'll be repeating it for both installs. Obviously two separate installs would only require one system folder of which you'd share as nothing changes in system. If it were me, I'd probably just set up a route in your config/routes.php file.
Something like the following (presuming you have a controller called 'kowmanager' inside a folder called 'kowmanager' in your controllers folder):
// This would redirect all calls to kansasoutlawwrestling.com/kowmanager
// to the kowmanager controller.
$route['kowmanager'] = "kowmanager/kowmanager";
// Redirects all kowmanager/method requests to the kowmanager folder
// and a particular controller
$route['kowmanager/(:any)'] = "kowmanager/$1";
// Redirects all kowmanager/method requests to the kowmanager folder and a
// particular controller and method inside controller.
$route['kowmanager/(:any)/(:any)'] = "kowmanager/$1/$2";
Might not be the best option, but it means you won't repeat the same code twice and you've essentially created two applications inside one. There are numerous other ways of doing this including some rewrites in your .htaccess file.
If you want the easier option, go separate installs and be mindful of code repetition. Stick to the DRY (Don't Repeat Yourself) methodology.

Where should I place downloadable files for my component?

I am developing a Joomla Component which will allow visitors to download a sound file (be it mp3, or wave, does not matter). Those files are managed in the admin interface and can be unpublished in there.
Therefore, it seems that placing them in the assets section is not an option, as it would make them accessible directly from the server. I want to avoid direct access and only serve them through my MVC structure (usnig RAW document type) after verifying that the requested file is published.
Are there any conventions on the placement of those files inside my component's directory structure?
My first idea is to create a folder inside the administrator/components/com_mycomponent and keep the files there. Do I need to restrict access to this new folder with a new .htaccess file, or is it already taken care of by Joomla with a global .htaccess?
you should place the files in the media directory. It is supported by the installer and is much better place. The logic is to have code in com_mycomponent for site and admin and both of those will share media (images/css/js), downloads, etc...
/media/com_mycomponent/
Restrictions are up to you.
Here is Joomla installation structure, http://docs.joomla.org/Components:xml_installfile

How to "save" my wordpress blog's posts in same url format and remove wordpress?

I have a Wordpress blog running on my site and I have no time to continuously upgrade the software and I pretty much want to remove wordpress. It's broken at this point anyway, I can't really get into the admin area, but I suppose I could try to hack my way through.
Anyway, I'd like to save the posts that I have and keep them under the same URL structure so they're still relevant in the search results indexes.
Here's the site in question: http://www.danielfischer.com
Any suggestions on how to keep the site up but possibly turn it static yet keep the same url structure? A static archive of what used to be and have the urls still work pretty much?
Thanks.
You can use a mirroring tool like HTTrack to download the entire site to individual HTML files. HTT shouldn't have any problem making folders from the URL structure (though if there are any non-pretty URLs linked, it'll grab those too).
From there, just upload those files and call it an archive (maybe put them in a separate directory & point the server to it so Wordpress doesn't get totally wiped out, just in case).
Switch on WP-Cache or better yet, install WP-Super-Cache. Make sure it caches every page you have (set the cache timeout to never in settings). This will create static versions of every page within the cache folder. Once you have all pages cached, go into the cache folder (/wp-content/cache/supercache/%{HTTP_HOST}/ by default, where HTTP_HOST is your host name) and copy all of those files and folders into a new webroot (create a new site with whatever the hosting panel is you are using, or in apache manually). Switch your domain over to this new webroot and if everything is working, delete wordpress.
A good shortcut would be to setup a site (such as test.yourblogname.com) and point the sites directory straight into the cache directory (ie. point it to /wp-content/cache/supercache/hostname/). That way you can test it without risking anything.
This could be a help for you
http://www.setuptips.com/wordpress/recovering-a-broken-wordpress-blog-without-a-backup-copy/

Categories