I'm looking for a commenting system with a specific feature, and I wondered if anyone could advise.
I want to be able to load different comment threads without reloading the entire page, via JavaScript callbacks. That means I need a commenting system that allows multiple comment threads to be associated with the same URL, with threads defined by custom IDs.
I've just found out this isn't possible with Disqus. Although Disqus does allow you to associate a unique ID of your choice with a thread, it also requires a unique URL for each comment thread.
Does anyone know a system that does offer the ability to associate multiple comment threads with the same URL, via unique IDs?
Not sure if it's possible with either IntenseDebate or Wordpress - or maybe I need to write a custom Wordpress plugin (the page itself will actually be within a Wordpress install).
You should have no problems creating you own custom comment page by 'hacking' comments.php.
By using jQuery and jQuery.load you can call a php page where you have code to retrieve custom comments.
But messing about comments.php is not that easy. Therefore this page might help you get an insight in comments.php
This answer doesn't solve you problem, but hopefully it'll give you some ideas.
Related
I'm looking at a site someone else developed. We're using a child theme that is calling back to a lot of its parent's functions. There are about two dozen plugins. Somewhere in there is a bug that's preventing a theme setting from propagating to the rendered page. The problem is, I am not sure what's involved.
I've tried enabling wp_debug, but the page is fairly silent. I've inserted HTML comments into functions and templates that I thought would be involved, but I haven't found one that is actually involved.
Is there a plugin or some way to force WordPress to log every file/function that's loaded for a page? How would you approach this scenario?
This is probably not the best answer, but I've dealt with a lot of similar situations on some of my customers who own WordPress websites.
I usually download the database and website locally and setup a local website using LocalWP, but you can use any web server like XAMPP or WAMP, actually. In the end, this is helpful, because I can quickly find apply functions of my hooks by doing a full-text search on the project.
To track down the error, I echo some logging with a helper function which will also print hook information.
If the code of your child theme is reached, this is a good start. If your website renders with the parent theme, you can focus on the hooks and calls in your child theme and hopefully you will find the error.
You really have to bite the bullet and follow the chain. If your parent theme renders anything you should be able to comment your child theme step by step to pinpoint the cause of the problem.
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 am subscribed to a Drupal 5 site with the Advanced Forum module. When a user decides to delete her post, the post dissappears and the following posts are moved up.
So if #2 is deleted the existing #3 will become #2 and so forth. The problem with this is if people reference previous posts which are now incorrectly numbered. Consequently it can lead to much confusion or even make people angry because they feel a comment is not appropriate - which it isn't after all!
What we would like is that the deleted post is simply removed without renumbering the rest. There is no option for this in the settings, so I will most likely have to mod the files.
Do you know if there already exists a patch to accomplish this, or can you alternatively point to where I need to modify the code?
I am a experienced PHP developer, but Drupal is new to me.
Possible workaround would be to set status field in comment table to 0, instead of deleting the comment. THat way it would not appear in comment list and other cid's would not be changed. You could do this in a custom module with a hook but I am not sure what hook calls comment_delete, normally you would override hook_nodeapi
but comments if I remember correctly may be handled differently than nodes.
Look in the comment module under /modules and check out from what hook comment_delete is called and override that in a custom module, that way you would not have to hack any core code.
Good-luck
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.
This is a strange one and not ideal, but basically we have a Drupal site that has been using the core comments module to allow authenticated users to post and view comments for a node. We are now needing to extend this so that unauthenticated users can also post comments, but not view them. Authenticated users would only have access to view comments by other authenticated users. Only admin users would have access to view all comments.
Is there a way of doing this? The permissions do not seem to permit this flexibility (access comments is required to give a user the form, but shows all approved comments).
I've looked into using some Drupal hooks, but as far as I could see there is only the hook_comment function that occurs after the comments have been retrieved (perhaps there is a good way of making use of this, but my mind has gone blank).
Any suggestions? I appreciate hiding comments from certain users but allowing them to post them is probably not best practice; however, I need to work with what we've already got.
I can think of a way to solve this problem, but it's not the prettiest solution.
Create a custom module with your own permissions.
Overwrite the standard theme function that's used to render the comments. You should have the comment object available, so it should be fairly easy to see if the comments is from the anonymous user or a registered user, and can check which comments the user should be able to see.
Now there's a few problems in this, as comments can be threaded, so in theory, it is possible that a comment in a thread will be missing causing confusion and possible other bugs.
But like I said, this is a quick and dirty fix, with what you got.
Can't you use the comment moderation queue to achieve exactly this? Check your settings for the comment module (at admin/content/comment).
You can set in your theme template.php whether you want anonymous users to view comments simply by doing a check on whether a user is logged in, and not showing the comment if they're not.
eg:
function mytheme_preprocess_comment(&$vars, $hook) {
global $user;
if (!$user->uid) {
unset($vars);
}
}
Then in your comment.tpl.php, at the top:
if ( isset($content) ) :
To check whether the comment has been unset, so that you don't render a whole lot of empty divs.
There's undoubtedly better ways to do this which involve using a hook to avoid loading up the comments at all for anon users, but this code will do the job without much work.