Our main web page is Drupal and we would like to use Osticket as our issue tracking system, but there is a problem with Osticket: anybody can create new tickets.
We can protect this by .htaccess, but we don't want do that; we would like to make this protect by Drupal: only authenticated users should access the Osticket page.
Is there a way to achieve this?
Found a solution here:
http://osticket.com/forum/discussion/9910/integrate-with-drupal-7
Here is the relevant part:
Preamble
It just so happens I was doing some off-again on-again work with integrating this into Drupal.
If you're just interested in ensuring a user is logged you're right, you need bootstrap.inc and you're right you end up with useless blank pages.
Solution
I've yet to get to properly documenting, so try this and let me know if I missed something and I'll have another look, however the following should sort the issue:
Duplicate Function Names
osTicket uses db_query() and (I think) db_close() rename the functions to something like db_ost_query() and you'll be fine. (Note I put the 'ost' in the middle to help future find/replace) I can't remember whether all occurrences of the function needed renaming for it to work, but its probably a good idea to do it.
Location of the bootstrap
The bootstrap has all manner of issues if called from outside the root Drupal directory, I gave up finding an answer to this and just kept an file in the root that osticket would include.
Headers, Headers everywhere
Bootstrap seems to like sending additional headers out so you'd want to include your file in an appropriate location (i.e. one of the .inc files). I think this solved everything.
Disclaimer
Of course, remember this will break on any updates and any mods you add you'd have to take this into account. If I've remembered rightly this will get bootstrap up and running and you can run is_user_logged_in() and show or redirect the page.
Further Concerns
I actually had a greater goal in mind in my meddling and so I don't remember whether everything was perfectly cosy after this addition.
I do remember having further issues with headers being sent and when fully bootstrapping the system session usage interfering with ostickets sessions - I think this occurred later though and shouldn't be an issue for you.
An Alternative Solution
When googling, many people suggested simply creating a module and having it iframe the contents inside it, this might be a good enough solution for what you want and would require a whole lot less messing around with ostickets code.
Related
Before I get to the question, let me say that I saw a similar question here with a fairly detailed response:
https://wordpress.stackexchange.com/questions/115211/loading-wordpress-stuff-on-laravel-site
And it was the closest thing I have found on the web to what I'm looking for, but the potential solution looked like it might end up being so laborious as to not be worth the time. Here is my situation:
I develop and maintain a small custom SaaS program that typically functions on a subdomain of a client site (say, software.client.com). The latest version of the code was rewritten using Laravel and there were a lot of gains associated with that. In the past, when the program was basically procedural spaghetti, if we had a client with a Wordpress site on their primary domain, we ran some atrocious (by best-practices standards) hack-around code to pull the Wordpress header and footer onto the pages of my program - sitting, of course, outside the CMS - while modifying meta tags and doing a number of other things. It wasn't pretty but it worked.
Now I'm in a situation where I'd like to solve the same problem - that is, to at least pull the Wordpress headers and footers onto some of the Laravel subdomain views - but nothing I have found on the web so far has enabled me to make much progress in that direction. I have found a lot of tutorials explaining how to integrate Laravel and Wordpress, or use one for frontend and the other for backend, etc., but nothing yet about the specific type of integration I'm talking about.
What I have tried so far is implementing some of the code I've used elsewhere into various parts of the Laravel codebase. Most of the recent experiments have been in public/index.php and in Controller methods. Laravel will allow me to get as far as including the Wordpress config, but if I attempt to go any further I cause a 500 error. Here's an example snippet that actually attempts to do more than I need, but I can't even get past wp_init(). Imagine the following code in a Laravel Controller method. The first two lines are OK, but:
public function index() {
define('WP_USE_THEMES', false);
require '/path_to/wp-config.php';
$wp->init(); // from here on, 500 errors occur
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();
// And then, at some point, I would call and modify get_header()
(I didn't really expect this to work from the Controller, but it doesn't work from anywhere else in the codebase I've tried either.) This is not a situation where I want to hand off control from Laravel to Wordpress for these URLs (I need Laravel functions / DB queries and more flexibility, and I know I could just do that hand-off through public/index.php and routes.php if it would solve the problem). And for these intallations, I don't need to grab posts or other items from Wordpress. I would just like to find a way to pull the header and footer into these views directly from Wordpress while maintaining control of the views in Laravel. If I can't, among other things, the design team will end up rebuilding headers and footers for every program install on a Wordpress client (for the time being) and they will have to make changes in at least two places when things are modified or updated.
If we have to, we will find a way to live with that until the next program version rollout, but if I can build a solution in what my superiors will deem a reasonable amount of time, we would all be happier. I hope that I have just missed something simple somewhere and I will be embarrassed to find out that I could have solved this in less time than it took to explain the problem. Thank you for any and all helpful responses and potential solutions.
You're not going to be able to cleanly merge the two codebases together. That would cause a disaster.
The complexity of the solution depends on the complexity the information you need to share. The simplest solution possible would be to write something custom to WordPress that builds a document with no body data and just supplies a token, like {!! $body !!}. Then, in Laravel, you can do an HTTP request to localhost to fetch this tokenized content. Store the result in a memory cache and use Blade to render the final view.
Essentially, my suggestion boils down to: Create a Blade layout with WordPress.
There's a thousand different ways to do this, and all of them are wrong.
I've been trying to figure out how to make the current SlickUpload 6.1.7 play nice in a form that does not require someone to include files. We want it to be optional. This form is for people to contact us, and we want to give them the option to include attachments, just not require it. It works if you upload a file, however the form will not submit, if you do not upload any file.
We are trying to use the Ajax version with Memory stream, but the 'AspNetAjaxCs-VS2010' sample code is not helping much... the documentation is sparse, and the samples have little constancy between them, making it hard to understand how exactly it all works. (at least for me) The fact that they got bought out, and the new owner company pretty much ignores people unless they are paying for it, is not cool.
Any ideas?
You could use a div to detect a drop inside your page. That way you could only activate it when the user really need it, or whenever the using actually select something for uploading, like a trigger.
I'm not sure I understand your question, but if so, it sounds like you already have a form that you want to use SlickUpload with to upload files IF there are files to be uploaded. Are you using the CustomUploadStreamProvider form?
I am working with a pre-existing zen-cart site has been worked on over the years by multiple teams. Backtracking through all of the teams is not a viable option. Some of the development teams implemented some hacks, one of them being replacing how zen-cart normally creates links, and I am stuck as to how they did it. For example, zen-cart normally links to a product through a link such as the one below:
http://yoursite.com/index.php?main_page=product_info&cPath=67&products_id=823
Instead, this zen-cart installation is doing the following:
http://yoursite.com/item-name-here-p-45-.html?cPath=1_26
I have figured out that the number after p-, in this case 45, is the product ID. However, I am stuck as to what that .html file is actually referencing. I am guessing that it is somehow feeding that data back into the index.php file, and it was done for search engine optimization purposes. The server is using nginx if that makes a difference. I would rather use apache for this site, but I am fine with nginx.
Additionally, there are also links such as:
http://yoursite.com/sitemap.html
but there is no file called sitemap.html on the entire system. However, there is a file called sitemap.xml
For a myriad of reasons, I can't link to the actual site and I hope you fellow developers can understand that. However, if anyone has any idea as to whats going on here, I would be very interested to know. I will provide what other details I can.
I just figured this out, and I want to share my answer for anyone that stumbles upon this. This was caused by something called Ultimate SEO which masks urls with html links to make them more search engine friendly. The reason there are no actual html files involved is because Ultimate SEO creates a .htaccess file that reads the filename from the URL, and converts it to parameters to be passed to a php file. I just simply disabled Ultimate SEO from the zen-cart admin page. Furthermore, Ultimate SEO is something that is used outside of Zen-Cart, so if you are having the same issue I did, this might be it, or something similar.
Several popular CMS's such as Drupal, Wordpress, etc. have an index.php file that is pretty much empty except for a include/require statement that includes some other PHP file (as in one file) containing all of the bootstrap code for the CMS. What is the rationale for this? Why not just move all of the bootstrapping code into index.php if it is doing nothing other than including the bootstrapping code anyway?
I'm trying to build a CMS as an example project to improve my PHP skills, and I'd like to understand what design considerations led them to do it this way. I understand the benefit of breaking up applications into multiple files, but I've never heard of making a file that does nothing but include another one. Obviously there is some benefit, since several major CMS projects designed it this way, but I just can't figure out what it is.
Can someone explain to me the reasoning for this?
In Drupal's case, there are other files that do a similar bootstrap. These typically aren't normal pages, but do serve important purposes. Off the top of my head cron.php, update.php, and install.php do this. I use the bootstrap process at the beginning of custom import scripts, as well as scripts that get called by cron that I don't want to use a hook_cron for.
I can think of two reasons:
When using a product like Wordpress, you sometimes end up adding user hacks to the front controller - say, setting custom constants, specific redirects, or an additional layer of access control, or whatever. An empty index file allows you to add that kind of stuff without disturbing the product's original code.
Having everything in a separate bootstrap creates the possibility of moving all code (including the bootstrap) to a location outside the web root, and include it from there.
Aesthetics mostly. You can have a clean and neat directory structure (outside of webroot), in which bootstrapping files are separated from index.php file. There are probably several of them (vs. one index.php file) and they are doing different things (db init, authorisation).
I also found one or two CMS which start in debug declaration (in order to switch display errors and warnings before including any files, so you can have your errors printed before php includes a file with syntax error, but that's not really a good practice).
I would say this is good design because you can easily change the path to the bootstrap, which makes it very easy to change location of the CMS, if ever necessary.
Another good reason is you could also be running a dev CMS while developing, and roll out new versions with one path change in the index.php.
I've built a complex site for a client, who wants this duplicated, and re-skinned, so it can be used for other means.
What is the best way of doing this? I'm concerned about copying every file as this means any bugs must be fixed twice, and any improvements must be implmented twice.
I'd look to refactor your code.
Move common functions into a library you can reference from both projects. As you mention that the new site is for a different purpose then you are likely to see divergence and you don't want to hamper yourself later, so extract the common parts and then modify copies (or if appropriate new files) of the remainder to complete your fork.
If you haven't applied good practice already then now is the time to do it and it'll make your work on both sites easier moving forward.
If all the functionality is the same and only the layout is different you could just create a new css file. 2 websites could have exactly the same code base but have different stylesheets and look completely different.
I think that using a version control system like subversion or preferably git, is a good way to duplicate your website. You will be able to track the changes that you make and revert to older versions if things do not work out.
You should implement some kind of instantiation, so look and feel, content and data will be shown depending of what instance of the application is accessed.
In other words, each application access to the code with a different application identifier, meaning content will be served depending on it.
Both application identifier will be pointing to different settings, so stylesheet and content will be absolutely isolated, and both domain will be living in the same IIS application.
If you want to duplicate a whole site it's probably best to copy the whole thing and amend as necessary. Obviously taking great care not to copy large portions of text or else you may be penalised by the search engines.
There are ways you could put the new site onto the same shared host (say within a subdirectory of the original site) and literally 'share' some files. If a unique change is required, you could instead reference a 'local' version of a particular file.
However that sounds like a recipe for a headache to me. I'd prefer to duplicate the whole site. It would be much easier to replace one or two functions on separate websites than it would to try and work out which website(s) are affected by a particular change to your source.