I've brought this issue to the OS-Ticket community forum but haven't yet had a reply. I'm trying to install the latest version (1.7.0) and am getting the error:
Unknown or invalid schema signature (d959a00e55c75e0c903b9e37324fd25d .. 9e85d0c8f8532e3b0be38e99aba07aa1)
I've looked at the source code but am still unsure why this error is being generated. Does anyone know how I may be able to go about resolving this issue or what may be causing it? I've installed the system previously on my local machine without issue, the server i'm installing to is however Windows and so i'm wondering if there are any known things to be aware of when dealing with this system / MySQL on windows.
If I can't find a solution are there any recommended ticket support systems I could perhaps use instead?
Many thanks in advance.
Just change the second part of signatures in the file-
include\upgrader\streams\core.sig
Reference
There is a post in their forums for a workaround.
Post #5: http://osticket.com/forums/showthread.php?t=13703
I contacted the Dev Team about the workaround around a month ago and they advised against it, telling me they were working on fixing it; and to give them 2-3 weeks. Thus far, I have contacted them again with no response and have found no fix.
I have not heard of anyone using the fix reporting issues. Still, comes with a "Use at your own risk" disclaimer I would say.
Related
I'm a little lost here and didn't know where else to go so I thought best place to ask would be here... So, I recently upgraded my site's server from shared to VPS after which I attempted to download an Excel report from my DB like I usually would do regularly. However, since the upgrade after I download it, I get an error when opening the documents; it gives me the option to still open it but it is clearly corrupt or something. I have attempted to debug this issue but I am most definitely struggling with this one. I've also made sure I'm using the most recent version of PHPExcel but sadly this didn't resolve it. The error I'm experiencing is as follows:
The file format and extension of "myReportName.xls" does not match.
If anyone can shed a little light on what might be going on here I'd really appreciate it, and thanks in advance!
UPDATE: I don't think this would affect it, but I thought I'd add I also had a bug with my DB after the upgrade where nothing would insert due to fields not having a default value. They worked fine on the shared server but on the VPS I had to edit all my columns to have a default value of null. Also in case someone asks I didn't think it was necessary to post my code as it was working fine before the server upgrade so I thought the bug wasn't there, but if I'm wrong feel free to let me know.
I've messed up a little bit with my php cms insallation and now I've problems loading the mediawiki Main_Page and I don't exactly know why. The error thrown by the server is a simple 404, so it doesn't explain that much to me. The only thing that could help me find out the solution is that I changed the virtual host configuration a couple of times in the server (Apache 2.4).
I'm guessing the problem is there but I don't have any further clue about how to solve it.
Has anyone experienced something like this?
I've to add that this is not a short URL problem, as i'm not trying to redirect the articles pages to a specific url, so this shouldn't be useful in my case.
From the information you provided, i guess you got some error in your pathing.
Have you tried running it locally via e.g. Mamp ?
Play around with you local_settings especially $wgScriptPath and $wgStylePath.
The error can usually be found in there, and fixed in there. I have been working with MediaWiki the last couple of weeks. If you provide some more info, i might be able to help you some more.
im using joomla3 for my new site , i used 3.2.2 and currently update to 3.2.3. but its always giving me mysql errors form several tables when browsing ste also saving values from backe end
Error displaying the error page: SQL=SHOW FULL COLUMNS FROM sltdb_template_styles: SQL=SHOW FULL COLUMNS FROM sltdb_template_styles
How to overcome this .. please advice ?
It looks like database connectivity
Try to access the database from the application server using the command line. or try to access your database via PHPAdmin
If still no chance:
Here is fix - i got for google
Use Extension manager->Discover and Install, possibly followed by an Extension manager->Database and Fix when needed.
Joomla requires a proper working infrastructure. Something must have failed otherwise the update should have succeeded. The above steps are normal procedure for fixing when something went wrong. An alterative would be to restore and try again.
Also, Joomla allows you to break down the steps. Using the Extension manager install from directory is the least resourceful way to update. It requires you to download, extract and copy it to the webserver yourself.
Hopefully this will help someone. I had this issue after a server move and it turned out that it was due to a module (wp_posts) that had old db credentials in it, i corrected the credentials which fixed the issue.
Unrelated but one other thing to check if you have this type of issue is can you update things in admin, I had a secondary issues with was that APC cache was not enabled on the new webserver, i discovered that by trying to update things in admin and viewing errors.
The error 0 message is very unhelpful, it seems this could be module specific though rather than joomla itself but it seems quite poor that a module can block the entire site form working, some error trapping needed me thinks!
Cannot comment, yet ... (as a comment to logicc's answer)
Well, the "Error: 0" is indeed not very helpful, but with debugging turned on, you at least get a good idea of where the problem might be coming from:
24 JDatabaseDriver->loadObjectList() /.../modules/mod_wpposts/helper.php:91
25 JDatabaseDriverMysql->connect() /.../libraries/joomla/database/driver.php:1312
About the module blocking the entire page - that might make sense in some cases (a module so important that you would rather have the page not render, at all, than in part?), but it certainly seems like a bad default. For now, I think modules should take care of that themselves with some try-catch-ing.
I have tried looking everywhere for an answer but i can only find references to Unknown Type errors, this seems to be different.
I have installed a nightly snapshot build of solr (apache-solr-4.0-SNAPSHOT.war) which i have had to do because the pdfbox library that comes with stable is too old and would not read them. but that's another story.
What i have at the moment is an error from php SolrClient::AddDocuments() with the error message from the exception as 'Unknown style "html"', please can someone explain what could be causing this error.
Thanks in advance.
This appears to be a difference in the structures of the config files. I edited the schemea.xml and solr-config.xml files and the error disappeared. Exactly what change made it disappear I am not sure as I amde several at once.
Thats the best answer i have.
I am not an expert in PHP, still learning it. I'd like some hints on how to troubleshoot problems.
Recently I installed PHP 5.2.9 on Vista+IIS7 (phpIsapi). I ran a script that did an opendir()/readdir(). This script ran just fine on 5.2.0. On v5.2.9, it failed but I got no indication of the source of the problem.
I banged around in the dark to troubleshoot it, finally trying different directories and narrowing it down to a directory perms issue. More banging around to figure out which user needed perms. Though the page runs as Network Service, the user that needed perms on the dir was IUSR. And it needed RX perms on the entire traversal tree. Who knew?
I also worked with a bunch of COM components. Some of them worked, some did not. They often failed with "No error". Again it was bumping around in the dark until I solved the problem.
I tried error_reporting(E_ALL | E_STRICT) but that gave me nothing more useful.
I know this can't be the way that people do troubleshooting as they develop on PHP.
Any hints you can provide on efficiently working through minor issues as they come up?
http://www.xdebug.org/
Well, my answer is: no, there's no good way.