I am maintaining a Joomla 2.5 based magazine website with 3-4 new, long articles every day.
Smart Search was enabled by default and now I've got a few "finder" tables full of indexed phrases and therms.
I wonder if there are any disadvantages if I'd:
Disable the Smart Search plugin
Remove these 'finder' tables completely
Aha, we're using a Search field, which works fine, but I'm not sure what's going to happen if I disable the plugin and remove these tables. Will it then search for phrases in content Joomla tables or simply break w/o missing 'finder' tables
Has anyone tried this before?
I really doubt about having Smart Search enabled by default. Smart Search is one of the coolest (and sometimes unknown) features in J2.5. But it's not for all websites. You just need to test it!
Here is what you can do:
You can certainly disable the Smart Search plugin, IF you are not using Smart Search (or you think you don't need it). The old search will still be there to use.
I would strongly advice against deleting tables (just empty their content if you really want; can be done from the Smart Search Management GUI); you may / will have problems later when you update Joomla.
Most important, don't do this kind of stuff on your live server. Nowdays it's almost as easy as you can get to run Joomla! on a XAMPP or WAMP intalation where you can test everything.
Smart search is a much more powerful search than the old search since it indexes your content and returns it in a sensible order and lets you do filtering and maps.
If you really want to disable it you would disable the finder content plugin. Then you can clear the table in the smart search manager (I think it says purge index or something like that). I wouldn't uninstall because you may want to go back.
I was thinking to delete or empty the FINDER table. But the best solution for big websites is to
Disable the CONTENT SEARCH plugin and
Use the classic search module.
My user experience remained the same.
Related
I am using the free plan for a personal project, so can't afford to move to a better (paid) one. Unfortunately, my database filled and stupid me did a reset, thinking it will delete only the rows, leaving the structure intact. But it deleted everything, so now I have to rebuild it.
Before I start, I'd like to know if there is a way to empty old records/rows from the database. If I could manage to do this automatically (ideally there are some heroku settings that can do this, something I've missed), so I won't reach the 10000 monthly limit, it will be great.
There are no safeguards built into the platform to delete rows on your behalf. You will need to do it manually or teach one of your applications to do it programmatically.
I have a bit of bad habbit, I install joomla on xampp and test all extensions and things im planning to add on the website there. Then I go to live website and try to start it from scratch, but it get very confusing and stressing this way..
I am thinking of just uploading the xampp joomla site to a live server but I am worried about these things:
I have installed/uninstalled some extensions (10+) do these leave behind any corrupted files in general or cause any problems?
Any tips cause im really worried now, the website has grown a lot and I cant start it from start even looking at the notes I took while making it. Uninstalled extensions do they leave any files behind or cause any problems? Right now the website works good on XAMPP.
Any tips or suggestions greatly appreciated,
Ammy
Most extensions uninstall fairly cleanly. You can be sure by using an FTP client and looking under /components, /plugins, and /modules (and/or their counterparts under /administrator) for leftover directories with the extension's name. You can also use PHPMyAdmin or somesuch to look for leftover database tables with similar names.
Even if files and tables are left behind, they're unlikely to cause problems with the site. I understand the desire to keep a tidy codebase, but that's not a good reason to build a site twice.
Most extensions delete their files on an uninstall. This is because Joomla does this job itself, the extension doesn't have to do anything for this to work.
However the tables are a different beast. While it would be very easy for extensions to delete their tables on uninstall, there are different ideas about this. Some argue that they don't want to be responsible for deleted data and thus leave the tables behind.
Also entries in the assets, categories, tags mappings and menu tables are likely to be lying around after an uninstall. Most extensions will not clean those tables up during uninstall.
There may also be leftovers in files, if the extension used some library like fof or similar. There is no ckeck if the uninstalled extension was the last one that used that library. So you need to uninstall those manually, but you need to know if it's used or not.
The leftover tables and entries don't generate any problems except for a bit more memory usage. However a leftover library may be a huge security issue as it may contain a bug which could be abused. Since no extension is using it anymore, it will never get updated and the bug doesn't get fixed.
I want to know if a extension (for example: joomfish) is really used or not used at all before i disable it / uninstall it.
Is there a way to check ?
First, in Joomla plugin has a specific meaning, so what you want to know is whether a component, module or plugin is used.
This is a common problem when you inherit sites. A lot of times users install tons of extensions and never use or uninstall them.
The simplest first step with modules and plugins is to see if they are published or not. Also you can look at modules and see if they are assigned to any positions or menu items.
In terms of extensions, if they are a kind of extension that would be used to create content and you look at the manager you can see if any content was ever created. If not it is probably safe to uninstall. IF there is content then you will want to figure out whether you need o preserve it.
The problem with Mike's answer is .. how do you know if you have tried every possible combination of things or possible events with enough certainty to say for sure that something is not running ever. For example you may have a component that you never use as a menu item but then some module is running a query against its data.
Well you cannot know that. To be absolutely shure you could write a system plugin which gets triggered on plugin calls and logs the triggering plugin names.
For about 12 years I've been working on a couple different web sites in Dreamweaver or even wayback in Homesite. That said, I've gotten very comfortable with the traditional set up of URLS with definite structures where you can logically follow the directory set-up and it was very clear how to program the relative/absolute links and more. I would either FTP the files through in Dreamweaver or would use some kind of Management Console. Recently I took a new job to help on a web site that currently lives and was built using Joomla. I'm looking to see if there is a way to get this entire site on my Hard Drive so I can work on it locally and then upload as pages are finished, or at the very least find out how best to work with this site.
Joomla has many things about starting a page from scratch, but I'm really trying my best to investigate a site that's already developed and find ways to make the necessary adjustments and take inventory of everything that's on the site. Any help would be much appreciated.
Thanks.
In order to administer a site in Joomla, there is no need to have any files locally. You can add, edit, and delete pages all through the administrative back end of the website. The entire site is built based on the query string of the URL. The string determines which component is displaying the content and which content to display.
There is really only one page in a Joomla site, the index.php file in the current template directory. Every page is built using that page. The only time you would need to modify that page is when there is a structural change in the site. Even then, if the template is well coded it should have various module positions available for use that collapse when they are not in use. This allows you to have a 3 column layout on one page and a 2 column layout on another simply by adjusting which modules display on a particular page.
I would highly recommend reading some tutorials before messing around with editing any files. Here are a few decent resources:
http://www.virtuosimedia.com/dev/php/joomla-administration-explained-a-joomla-15-admin-tutorial
http://www.joomlashack.com/tutorials
http://docs.joomla.org/Beginners
Part of the purpose of Joomla is to be able to manage the content of a website without requiring local copies of all the pages. So what you are asking sort of defeats the purpose of using Joomla in the first place. To do what you ask you would have to get an offline copy of the entire website, uninstall Joomla, and then upload your "static" copy. I would predict that the end result would be a web site that is very hard to maintain.
If you really really want to do this you could use a website copy tool like HTTrack. It supposed to be used to copy a website so you can browse offline, but the end result is what you are looking for: a local copy of the website.
We're having a spirited discussion about this at my workplace. We're talking about user uploaded images for a bunch of products, not images needed to display the basic site. I say "no way" but I'm curious what others think.
Update: Just to clarify. These are customer supplied images for products that they are entering/modifying.
I agree with 'no way'.
Anything that may change on the site through day-to-day use, or is editable by whoever administers the website I consider to be 'content'. This includes uploaded files and database content, both of which are backed up separately. Nothing on the website that is in version control changes once it's been deployed. Easier that way.
Other ways of asking if something should be in version control:
Do the images change?
Are the changes related to anything else?
Can mistakes be made?
Is traceability wanted/needed?
If the rest of the site is version controlled, version control the images.
If the images are generated, version control the generator.
Presumably, what you are talking about is content that would be classified as user data, as opposed to project files. That stuff, while important, does not need versioning - that needs a plain old backup mechanism.
I recently added a new project into a fresh SVN repository, and every time I look at the 'uploads' folder I realise how stupid I was to include that in the initial commit.
It seems like what you're talking about is content that is in (or perhaps will be) in a database. If a customer is supplying you a list of products as well as the pictures of those products, then that should all come from a database. In this case, I wouldn't because your database should be backed up, but not in the VCS.
If it is not, and your web site is static, then I would only because it is "part of the site."
If you feel you must revision it, put these resources out of the path of the main repository somehow, and then give it a dedicated repository just for that content.
You don't want everyone who has to check out code getting a copy of every image when they checkout or update, its slow, and pointless, and having them in your primary tree will just have more headaches than you can Imagine.
/common_ancestor
/project_code/ # repository a
/resources_dir/ # repository b
If you have to use symlinks or web-server magic to make this happen, then do that, but whatever you do, DON'T put content like that in your main repository.
As far as backups vs revisioning go, revisioning it like this does give you a slight ease if you're using SVN as your distribution method as well, that way if a developer needs a copy of the images for testing purposes, its relatively easy to get a relatively up-to-date set of them.
If you aren't going to expose the versioning to the customers, then what would be the point?
The customers are already free to use version control on their own end, before they submit the files. You may want to encourage them to do so.